The agent loop

Product triggers become agent runs, and every run writes back to product state. The agent loop is the one path that turns product state into agent work and turns that work back into product state: something happens in your workspace, an agent runs on your machine to handle it, and what the agent does lands back as real records — comments, status changes, questions, approvals, summaries — that can set the next run in motion. Closely timed comments and reactions in one task conversation combine before they enter the loop, while assignment, schedule, workflow, and recovery triggers keep their own timing. Every agent that does anything in Task Machine does it through this loop. Once you see the loop, the rest of the product reads as the surfaces that feed it and the records it leaves behind.

Every run follows the same path

There is a consistent path where product events become agent runs. Whether the run comes from a message in a chat, a conversational steering batch, a task assignment, a schedule, a team lead's heartbeat, or a workflow step, Task Machine does the same four things. It identifies the acting agent, selects the worker to run on (the worker the trigger named, or the agent's default), assembles the prompt the agent will follow, and records the run with its prompt and starting transcript before the machine ever sees it.

Two details make the loop coherent. Every run records both the input — the human request or system instruction that triggered it — and the compiled prompt the agent actually received, so a run is always inspectable after the fact. And every run is bound to a working folder keyed to the thing it is about: a task run works in the task's folder, a chat run in the chat's, so the agent's local files line up with the record it is acting on. One path, one prompt shape, one folder per container — that consistency is what lets every trigger behave predictably.

The compiled prompt is everything the agent needs

An agent does not improvise. Before a run starts, Task Machine assembles one complete set of instructions — tama never builds prompts, it only carries finished instructions to the local tool and streams the result back. The compiled prompt brings together, in order:

• The agent's identity — the profile's summary and instructions, the standing guidance that makes this agent itself rather than a generic worker.
• The CLI contract — how to use tama to make durable updates instead of describing them in prose, with a pointer to the per-command-group skills (taskmachine-tasks, taskmachine-documents, taskmachine-propose, and the rest) that ship with every agent.
• Its memory — the agent's bounded markdown memory, injected on every run alongside guidance on what is worth keeping, so the agent stays consistent across jobs.
• Relevant knowledge — documents pulled in by relevance to the request, plus explicit workflow context references when a workflow step names them, filtered to what this agent is allowed to see and to the project in scope, so context never leaks past permissions.
• The trigger context — the current ids and metadata for the task, project, chat, comment, or workflow this run is about.
• The trigger input — the actual request: a person's chat message or comment, or, when the system started the run, a standard work instruction (on an assignment, for instance, it tells the agent it now owns the task and must set it in progress, report progress, and write a summary when done).

Those last sections are the only part that changes turn to turn. The identity, CLI contract, memory, and knowledge frame every run the same way. The first-party capability skills are written into the run folder as real files, so the agent has working playbooks on hand rather than prompt prose to parse.

Triggers are the ways work reaches an agent

The loop is fed from several directions, and each maps to a surface you already use.

A chat message in Chat runs the chat's agent for one turn — one queued or running job per chat at a time, so a new prompt waits for the current turn rather than racing it.

An assignment is the workhorse. Assigning a task to an agent puts it in the workspace queue for its local, cloud, or scheduled lane. The loop shares each lane fairly across projects, then starts already-in-progress and higher-priority work first within the selected project, with age breaking the remaining ties. On pickup the agent sets the task to in progress and carries out the work spec that planning wrote for it before execution began (below).

A comment steers an agent through the task timeline. A human comment that tags an agent opens that agent's thread, and later human replies keep steering the same agent without another tag. A human root comment on an agent-assigned task steers the implementer. A comment that tags a team routes the thread through the team's lead. A reaction can also steer the author of an agent-written comment, so a 👍 on an agent's proposal means proceed and a 👎 means stop or adjust. Comments, replies, and reactions for the same task, agent, and thread wait until the person has been idle for one minute, then become one run with the complete current instruction set. Different agents and threads remain independent. Comment steering comes from human-authored comments, while reaction steering comes from people or from agents whose profiles allow it.

A schedule feeds the loop on its own clock. A one-time scheduled task becomes actionable at its time and a recurring task creates its next occurrence, and an activated task assigned to an agent flows into the same queue an ordinary assignment would.

A heartbeat is how a team lead supervises. At its configured interval, a lead agent runs with its team's queue, its members, recent activity, and the active goals it leads as context. Its first duty is to route queue work without an implementer to the right members — by exactly one path, a routed assignment or a single hand-off comment, never both, so it never double-fires the same work. After that it can look at goal progress and add a goal-linked task or project, and here its autonomy decides the shape: a lower-autonomy lead proposes it for you to approve, while a higher-autonomy lead creates it directly. Either way, every heartbeat records its own evaluation outcome on the run, so you can see the lead considered the queue even on a turn that routed nothing.

A recheck keeps blocked work moving. When an agent cannot finish a task because it is waiting on something outside the system, such as an email reply, an external job, or a deadline, it blocks the task and sets the first recheck with tama tasks recheck. An ordinary agent-authored block without an exact time receives a one-hour safety backstop. The required reason is recorded in the task event rather than posted as a comment. The loop does not infer the first schedule or source state from transcript text. At the due time, the agent works through still-open linked pull requests in bounded batches and verifies each one directly at its source. It checks the exact head and state, required CI, mergeability, source-host review feedback, and whether the head contains the latest fetched base tip. Requested changes, unresolved actionable feedback, a stale base, failed checks, or conflicts return the task to implementation. The agent addresses the feedback, rebases when needed, runs complete local validation, pushes and reports the new head, and then checks the source again. An already completed merge needs no retroactive approval. The turn records the merged state, writes the completion summary, and closes finished work without creating another Inbox request. Otherwise the turn either clears the block and continues or leaves the task blocked for another check. Successful checks repeat every 30 minutes for the first day, then gradually widen to one, two, four, eight, and sixteen hours before settling at once a day. A check that fails, times out, or is cancelled backs off faster: five minutes, 30 minutes, two hours, eight hours, then one day. An earlier time set during a turn still wins, and clearing the recheck or leaving Blocked ends the sequence. An unchanged blocker stays quiet. If a question, approval, delegation, review, or mentioned comment already owns the human action, the agent reuses it. Only a genuinely new human action creates a new request.

A workflow step runs through the same loop: when a workflow run reaches an agent step, it starts that step's agent like any other run. The workflow passes the step's context references into that run and later reads the transcript and generated documents through the same agent-run record, so workflow steps and ad-hoc work share one execution path.

Planning and review bracket the work

An agent-assigned task is not handed to an agent to "just start." Before the work is ready to run, Auto reads the task description and acceptance criteria, weighs the planning complexity against every applicable budget, and selects an available high-capability planning model. A straightforward, well-defined task can use an efficient planner. Substantial ambiguity, coordination, sensitivity, or difficult verification can move the task to a stronger one.

The planning turn begins by analyzing the task, its history, and the relevant workspace and repository context. When the outcome and execution direction are concrete, the planner writes a self-contained work spec with a Goal, Acceptance criteria, How to verify, Constraints and non-goals, Context reviewed, and Deferrals. This gives a fresh agent enough direction to carry out the work without relying on the original conversation. When several reasonable approaches would materially change the result, scope, architecture, risk, or rollout, the planner does not invent the decision. It asks one question in your Inbox with three distinct approaches, their trade-offs, its recommended default, and three editable suggested replies. Planning waits for your answer and then resumes on that exact task. Details the agent can inspect or research itself never become unnecessary questions.

When it writes the spec, the agent scores the task on four 0-2 risk axes: blast radius, novelty, sensitivity, and reversibility. Those scores derive a named review level (Routine, Standard, Elevated, or Critical) that sets how much scrutiny the finish deserves. The spec is written through tama tasks spec.

Once the Work Spec exists, Auto matches models separately to implementation, review, verification, and follow-up. It considers current model capabilities, pricing, and budgets on every decision. Task Machine also records terminal-task outcomes for controlled evaluation, where missing local history remains unknown rather than being treated as unsuccessful. This matching finishes before the plan proceeds. On a lower autonomy level the spec then holds for your approval in the inbox. On a higher one execution begins, following the same autonomy boundary as the rest of the loop.

When a plan waits for approval, its Task and Inbox reviews show the same risk assessment, proposed work, and Models section. The planning row is read-only because that turn has already happened. Every future stage starts on Auto, showing the model and reasoning Task Machine currently recommends. Keep Auto for the quick approval path, or choose another model available on the same worker and then choose one of that model's supported reasoning levels. Nothing changes when you open a menu: Task Machine saves the fixed stage choices together with the approval. After approval, the review keeps the effective choices visible in read-only selectors.

The finish is bracketed too. Planner and reviewer defaults resolve independently through the assigned agent, project, goal, and workspace. An explicit task role always wins, the implementer is the planner fallback, and human-review levels use the human task creator as the reviewer fallback. A reviewer assignment names who will judge the result. It does not start review work by itself.

Repository-backed agent work is reviewed before merge. The implementer explicitly links the pull request and reports each head with its required CI result and source mergeability. Before readiness, it also confirms that the head contains the latest fetched tip of the actual base branch and that no requested changes or unresolved actionable source-host feedback remains. Queued or unavailable checks keep the task blocked through a scheduled recheck instead of holding a run open. Feedback, a stale base, a failed check, or a conflict returns the task to implementation for correction, rebase, complete local validation, and a newly reported head. When the final reviewer is human, the implementer first reviews that exact head in a fresh session through tama tasks pull-request review. A pass releases the same revision and its pre-review evidence to the human's Inbox. A request for changes returns it to implementation without interrupting the human. An assigned agent final reviewer remains one fresh revision-bound review. Task Machine final approval is always required before the implementer merges an open pull request, and source-host approval remains an additional pre-merge requirement only when repository rules demand it. The implementer runs tama tasks pull-request merge-check immediately before merging and reports the merged state afterwards. When source inspection instead finds that the canonical linked pull request's exact current source head was already merged, the agent reconciles that head and state without inventing approval, writes the completion summary, and closes the finished task. A new head, newly failing check, or newly reported conflict clears readiness before any future review or merge.

Work without a connected repository keeps the completion-review flow. Review begins when an agent's completion reaches a gated review level or when an agent or person moves the task to in review, making the result ready to judge. Routine agent work has no separate gate, Standard and Elevated work uses the stored reviewer, and Critical work routes to a human unless someone was explicitly chosen. When an agent implementer is submitting to a human, it performs the first review in a fresh session. Only approve releases the result and its rationale to the human's Inbox; revise returns it to implementation and rethink sends it back to planning without creating human attention. Every corrected submission repeats that pass. A human implementer proceeds directly to the assigned reviewer, while an assigned agent final reviewer remains the single agent review. The final reviewer judges the delivered summary, acceptance criteria, and attached evidence rather than their own taste. Final Approve sends the task to done, revise returns it to in progress with the reviewer's notes routed to the implementer, and rethink sends it back to planning for a new spec. A person can also deliberately move a task straight to done. That exact state choice bypasses completion review and the agent-only check for unresolved questions or approvals, but it does not silently answer an open question or decide a pending approval. Those still wait in Inbox until someone handles them. Every verdict is a durable record on the task, so a gate that passes or sends work back leaves evidence, not just a status change.

The agent acts by changing product state, not by talking

The return half of the loop is what makes it more than a chat. As it works, the agent uses the tama CLI to make durable updates rather than narrating them: it comments and replies on the task, sets the task's status, writes to its memory, creates and updates documents, asks a question, requests an approval, proposes a task, project, workflow, or whole playbook, and writes the completion summary when it finishes. Each of those is a real record — a timeline event, an inbox item, a stored summary — not a sentence in a transcript that evaporates. The whole run streams back live as a transcript you can open on the task or chat, but the things that persist are the product changes the agent made.

Attention is a deliberate update too. Before an agent asks a question, requests approval, or mentions someone in a comment, it checks the task's history and open requests. One unresolved action stays one request across retries, reconnects, and later runs. Routine progress, acknowledgements, waiting updates, and unchanged summaries stay in the run rather than becoming comments or Inbox work.

This is the through-line back to the surface triad. The agent's questions and approvals arrive in your Inbox, its comments and status changes land on the Task, and the proposals it raises in Chat become records you accept or reject. You do not watch the run — you act on what it leaves behind.

Guardrails keep the loop from running away

A loop that turns results into triggers needs bounds, and Task Machine applies them before every run. A task runs one active job at a time — a second trigger on a busy task queues a follow-up rather than starting a competing run. Agent-to-agent steering is explicit: an agent's comment does not trigger another agent by itself, an agent reacting to its own comment does nothing, and a different agent can steer with reactions only when its profile allows that power. The workspace's run limit caps how many Runs it executes at once across all of its agents, and every Run still needs a free compatible Runtime, so real throughput is whichever is lower. And when a scope has a budget, the loop checks it before work starts: an exhausted budget pauses the run, writes the refusal onto the task timeline so the reason is visible, and cancels the queued job instead of letting it spend past the cap.

One guardrail is also a safety net. Because a completion summary matters, if an agent finishes a task without writing one, the loop starts a single follow-up run that does nothing but generate it — so the summary is always there, and the extra run only happens when the agent forgot.

Every turn is held to leaving a trace, too. When an agent looks at a task and decides to do nothing, it records why. And if a turn ends having changed nothing and explained nothing, the loop records that no-op itself. The point is that a silent, progress-free turn is never mistaken for one that genuinely had nothing to do — you can always tell a stuck agent from a quiet one, because every turn leaves a mark on the task's timeline.

Sessions resume so follow-up turns stay fast

Within one thread or chat, the loop avoids rebuilding the whole prompt every turn. When the worker supports it, a follow-up turn resumes the tool session from the previous turn — the agent already has its identity, CLI contract, memory, and knowledge from earlier in the session, so the resumed turn carries only the new trigger context and input. It falls back to a full prompt when no session exists, the session has expired, or the worker changed, and either way the prompt that ran is recorded on the job. The effect is that a back-and-forth thread stays quick and cheap without losing the agent's accumulated context.

Why the loop compounds

Put the halves together and the loop closes on itself: one trigger or a conversational batch starts a run, the run changes product state, and that changed state becomes the next trigger. An agent proposes a recurring task, and you approve it from the inbox. The schedule it created later fires and an agent picks the work up. The agent finishes, writes a summary, and asks a question that returns to your inbox. Work produces work, and your judgment sits at the points that matter — the approvals, the questions, the proposals — while the routine turns of the loop run on their own. That is the operating system this product is: not a chatbot you prompt, but a loop you steer.

From here, the loop runs on real machines and tools — see worker machines for where the work runs, and the CLI command reference for the tama commands the agent acts through.