What the agent workflow controls

Installing Uclusion into a coding agent installs a workflow, not just a set of tools. The skill and its references tell the agent when it may act, what it must record, and what it must ask before doing. This page describes the behaviour that workflow is meant to produce, so you can see what your agent is following and notice if something it does no longer matches.

This is a description of intended behaviour. The authoritative text is the installed skill itself, which the CLI keeps up to date.

Event delivery

Start comes only from an explicit Poke AI click by a human. An agent that is already working defers an outside target rather than switching to it. A Start that arrives as replayed history is history and is not acted on, and a deferred Start never activates later on its own.

Because Start is an untargeted broadcast, every live session receives a copy. Delivery is transport, not assignment. It is not a way to hand a specific job to a specific agent, so it should not be used while several idle agents could all accept it. Selecting the work directly in one agent’s chat is the way to do that.

Added, Updated and Responded are continuation events. They report that something changed on work already in flight. They never create or switch an assignment, and an unassigned session ignores them entirely rather than loading their targets. A job becoming executable is an update, so an idle agent does not wake up and start it.

A new session begins reading from the moment it starts, not from the accumulated backlog, so starting an agent does not replay old events as if they were new.

Clients differ in what they can do with a delivery. The Cursor IDE chat cannot be woken automatically, so a human starts the next turn there.

Assignment

One agent owns a job or bug at a time. Reading, classifying or reloading something does not assign it. An assignment a human made stays with that session while it waits for input or review, and ends on completion or when the human explicitly moves that session to other work.

Where work claims are enabled, an agent that picks up work on its own must claim it first, and starts only the item the claim service grants. If the claim is denied, every candidate is already held by another agent and the session stays idle. If the claim service cannot be reached, no claim exists, so the agent remains idle and says so rather than guessing.

Teams that deliberately want several agents on the same work can configure that. The single-owner rule is the default, not a limit.

Finding work

Whenever an agent shows you current work, it shows the complete list, numbered, with each item’s short code and its name. An entry is never presented as a bare code, because a list of codes cannot be chosen from. You should see this at an idle start, immediately after work finishes or hands off, and anywhere else current work is displayed.

An agent with nothing assigned and an empty list offers to explain how to add and work on a job rather than sitting silent. A first session gets one-time onboarding instead, immediately, before yielding the turn.

Stages and permission

Stage controls permission. Execution happens in Doable and Reviewable, and an executable stage is what authorizes implementation.

An executable stage authorizes implementation only. It does not decide how the work is tested, and it does not authorize introducing or expanding security behaviour. Both need a human decision. A test plan or a security plan already written into the job counts as that decision; otherwise the agent asks and waits for an answer before implementing. The security gate covers authentication, authorization, credentials and secrets, threat models, trust boundaries, security-sensitive persistence, and shared security infrastructure.

A stage also never settles a question that is open. An agent question raised from an executable stage moves the job to Requires Input, which bars implementation edits on that job until the question resolves and the job returns to its previous stage. It bars nothing else: investigation, reproduction, measurement and other authorized work continue.

Questions, suggestions and who authors what

Some replies to an agent question are advisory rather than authoritative, and the workflow marks which is which. An agent treats that rendered marker as the answer to whether a reply unlocks the work, rather than inferring authority from anything else.

Artifacts an agent creates in its own name need no permission, and the agent creates them rather than describing them to you in chat. Suggestions, questions and reviews are the agent’s own voice. Jobs, tasks, bugs and blockers speak in yours, so the agent creates those only when you ask. The distinction is whose name the record carries.

The practical consequence is that a finding reaches a durable record rather than scrollback. Chat may repeat what an artifact says, but never stands in for it, because a conversation ends and takes anything only said there with it.

A bug that turns out to need a decision between real alternatives converts into a job you own, carrying the original bug thread across as a task, in a single step. A bug is not converted merely to ask an open-ended question.

Design capsules

Before the first source or test edit for a piece of work, the agent loads the current design capsule for the exact thing it is implementing, and writes one if none exists. The capsule records the agreed outcome and stays stable unless you establish a new one. It is a contract about what is being built, and it is not permission to build it. Stage, testing, security, deployment, commit and push gates all remain separate.

Review and completion

When a testable piece of implementation is finished, the agent opens a review without asking first. The review is the durable record of what changed against the agreed design, and opening it is what brings the work to your attention. It does not change the job’s stage.

The review ends with a numbered menu of completion actions, mirrored into chat so you can answer in either place. Depending on the work, those actions are to commit the reviewed changes, push them, clear the notifications that work produced, and where the pass finishes the job, move it to Reviewable and run its completion sweep.

One reply authorizes all of it. This is deliberately a single compound decision rather than a series of separate prompts, and it is the one place the agent takes operational permission from ordinary chat. Reply with all, none, or the numbers you want, on the first line by itself.

The first valid reply governs, whether it arrives on the review or in chat. A later or conflicting reply does not re-authorize the work, and actions you declined are not asked for again. Selected actions run in order and stop at the first failure, and the agent then records exactly one account of what completed, what failed, and what remains, so a retry resumes rather than repeats.

Resolving a standalone bug ends the same way, with its own three-action menu on the bug itself. The trigger is the resolution rather than a review, because resolving is already the end of that work.

Completion sweeps

Resolving a standalone bug or a job entering Reviewable triggers a completion sweep. The sweep looks for two things: other work blocked on what just finished, and unresolved work the outcome has made redundant, obsolete, or in need of revision.

It reports and proposes. It does not resolve, edit or re-stage anything it finds. Later signoff, a shipped confirmation, a commit, or resolving the job afterwards do not trigger it again, so it runs once per real transition.

Recording progress

Work an agent picked up on its own always leaves a durable checkpoint before the turn ends, recording results, decisions, blockers and next steps, every turn and not only the first.

Writing a record is not the same as finishing. After recording something the agent continues every step it is authorized to take, and surfaces or creates the actual next actionable item before it stops.

Ending a turn

An agent does not end its turn while it still has authorized work it could do. Filing a question does not end a turn either; a question blocks only what depends on its answer.

When a turn does end, the agent says what it needs from you, including why the current work is blocked if it is. It ends with either a completion package, so you have the decision in front of you, or the current work list, so you have the next actionable item. An ad-hoc summary in place of one of those is not an ending, because it leaves you with neither a decision to make nor work to pick.

Token audits

Where usage reporting is available, the agent opens an audit before substantive planning and labels each phase of work, ordinarily planning, implementation, testing, and other. Every request belongs to exactly one phase, and the label applies from the next request onward.

An audit spans ordinary conversation turns. It closes when the work genuinely hands off for a blocking dependency, review, completion, pause or interruption, not because a turn ended. Collection finishes in the background, and incomplete telemetry never blocks the work itself.