Working with agents

Agents do the work in Taiga. You start them constantly, usually without thinking of it that way: describing a product, generating a document, generating initiatives, starting a run, remediating a maintenance finding.

Some agent work is not started by anyone at all. Maintenance sweeps follow your pushes, and the most urgent findings are queued for a fix without being asked. And when an initiative is done, the product’s as-built documents are re-derived from the repository, so the record of what your code actually is keeps up with the code rather than aging quietly. That one skips itself when the branch has not moved, so it costs nothing when there is nothing to see.

Your job is the two ends of that. Give an agent enough to work from, and decide whether what comes back is right.

You can also talk to one directly. Product chat answers questions about a product from its documents, its state and its code, and can draft an initiative or a document with you.

Where agents work

Agents are not one thing that writes code. They run at every stage of a product, and the work looks different at each:

Stage	What agents do there
Capturing intent	Interview you in Discovery, or read an existing repository, to produce the specification.
Design and planning	Generate the product documents from it, then plan an initiative in detail.
Implementation	Write the code in a run, open the pull request, and answer your review comments.
Analysis and maintenance	Sweep the repository for vulnerable dependencies, re-derive the as-built documents, review the work.

Grouping them this way is deliberate. Which agent handles which piece, and what each one runs on, changes often; what stays stable is the stage, and the stage is what tells you where your input matters and what a mistake will cost. The trust centre covers which models are used and what each stage is allowed to read.

Two kinds of input

Everything an agent produces comes from two sources, and it is worth keeping them apart because they behave differently.

Standing context flows down. Policies are set for the organization. Instructions and knowledge are set at the organization, the factory and the product, each level adding to the one above it. None of this is attached to a particular piece of work. It applies to everything, every time, whether or not anyone thinks to mention it.

Work flows forward. Whatever an agent produces becomes input to whatever comes next.

Any output is a product of both. When something comes back wrong, one of the two is where it came from, and they are fixed in different places.

Errors travel, so fix them where they start

Forward. Review a thing where it first appears, not at the end. Everything produced afterward is built on it, and nothing produced afterward will look wrong, because faithfully building on a bad input produces exactly what it should. By the time a mistake is obvious, it has been reproduced several times over.

Down. A problem you correct more than twice is not a problem with that run. It is standing context that is missing or wrong, and correcting the output leaves it in place for everything you build afterward. Move the correction up to the level where it is true, and it stops being something you catch. Write intake agents can act on is about doing that well.

Read the work, not the account of it

An agent reports on what it did, including checking off acceptance criteria it believes it met. Those are marked as verified by an agent, which is the point: it is the agent’s own account of its work, not an independent check.

The output is the work: the document, the plan, the diff. Everything else is a summary of it written by the same system that produced it. For anything consequential, read the thing itself.

The merge stays yours. A run ends at a pull request, and nothing reaches your default branch until you merge it.

Take the turn back before you edit

While an agent is working on something, that thing is read-only, and Taiga says why. It reopens the moment the turn returns to you.

This is deliberate. Editing an initiative halfway through planning produces a plan for a description that no longer exists. If you need to change something mid-run, stop first, then edit, then continue.

How long it will take

While an agent works on something, Taiga says how long that kind of work usually takes: usually 8 to 15 min while it waits to start, about 6 min left once it is running, and should finish soon near the end. Hover over or focus the time to see what it is based on.

The number comes from how long that kind of work has recently taken across Taiga, your own organization’s runs included. It is there from the first time that kind of work has been done. Until that kind of work has run anywhere, Taiga shows how long the job has been running instead of guessing.

When a job goes past its usual range it says Taking longer than usual. That is not a failure. It means the work is outside its normal range, which is worth a look if it keeps going. A job that stops showing signs of life says Stalled, and it is picked up again automatically.

A run counts down from the steps it has left, and shows no time at all while it waits on your review.

The same input does not produce the same output

Ask for the same thing twice and you get two different results, both plausible. A retry is a fresh attempt, not a replay, so it can succeed where the last one failed and it can fail the same way again.

Retrying twice is reasonable. Retrying five times is a signal to change an input instead.

The one job that stays yours

Everything above adds up to a single practice, and it is worth naming because it is the easiest one to let slide. Agents produce; you decide whether what they produced is right. Nothing reaches production without a person agreeing to it, and that agreement is meant to be real rather than procedural.

In practice it is the same act at four moments:

• A document, when it appears. Not at the end, when six others have been built on it.
• A plan, before the run. Pressing start is the acceptance.
• A pull request, before the merge. The diff is the work; the summary is written by the same system.
• A fix you did not ask for. An automatic remediation still ends at a pull request you merge.

Taiga is built to make this cheap: the review lands in Action Required rather than waiting on a page nobody has open, each output arrives one at a time rather than in a pile, and the audit trail records what was produced and who accepted it. None of that decides for you, and it is not meant to.