Here’s the loop, start to finish: an AI teammate is assigned a task, claims it, works over MCP against the joined spine — so it can see the customer and revenue behind the ticket, not just the ticket — opens a PR or deploys, submits the result for human review, and the outcome lands back on the same record. No step is skipped, and no step ships without a person signing off. This post walks each stage of that loop as it works in AIOProductOS today.
The reason to describe it in detail is that “AI agent” has become a word that means almost nothing. The mechanics are what distinguish a real teammate from a chatbot with a job title. (For the definition itself, see What is an AI teammate?.)
Step 1: the agent claims a task
You assign a task to a named AI agent the same way you’d assign it to a person — it holds a seat on the team, with a name and a role, alongside your human colleagues. The agent claims the task from the same queue everyone else uses. There’s no separate interface and no proprietary side channel; it competes for work on equal terms.
Claiming matters because it’s auditable. A named agent that claimed a specific task means you can always answer: what is this agent working on, and who assigned it? Anonymous “AI mode” toggles can’t answer that.
Step 2: it works over MCP — and sees the spine
This is the step that separates a useful agent from a shallow one. The agent connects over a spine-level MCP with 71 tools, and those tools read the joined customer-task-revenue spine. So when the task is “implement the export the Brightline account keeps asking for,” the agent doesn’t just see the ticket text. It can read that Brightline is a paying account, what they’ve requested before, and what revenue sits behind the work.
That context changes the work. A ticket says what; the spine says why it matters. An agent that can see the customer and the revenue behind a task makes different, better-informed decisions than one staring at a title and a description.
The difference is structural. A tool-MCP returns one system’s data — the tracker’s view of the tracker. A spine-MCP returns the joined record: the same customer’s subscription, feedback, support history, and the work in flight, all on one object. We explain that data-model distinction in full in Spine-MCP vs tool-MCP. It’s the prerequisite for context-aware agent work.
Execution happens on your side, with your model credits — bring any LLM via MCP. We don’t proxy your tokens.
Step 3: it opens a PR or deploys
With the work done, the agent produces a concrete artifact — a pull request, a deploy, a drafted change. This is not a suggestion in a sidebar. It’s a complete unit of work submitted the way a human colleague would submit it.
The artifact is attached to the task. The dev-loop view shows the task, the PR, and the deploy on one record, so there’s no hunting across GitHub, the tracker, and a chat thread to reconstruct what happened.
Step 4: a human reviews
Every artifact lands in a review state. A person reads it and approves or rejects. Nothing merges, deploys, or takes effect until that sign-off happens.
We keep this step deliberately, and it’s worth saying why, because plenty of vendors are racing to remove it. The agent handles scoped, checkable work well — but a human is accountable for what ships to customers and to production. Review is the mechanism that catches the mistakes an agent makes confidently and fast. An agent that could auto-deploy unsupervised isn’t a more advanced teammate; it’s a different product with a categorically higher risk profile. The review step is what keeps the agent in the teammate column rather than the liability column.
This is also the honest boundary of what the loop does. The agent doesn’t decide whether the task was worth doing, or whether the implementation is the right call strategically. It does the work and hands it to someone who owns that judgment.
Step 5: the outcome lands on the same record
Once approved and shipped, the outcome is recorded back on the same task. The request, the work, the PR, the review, and the result all attach to one object. Look at any shipped task later and you can see who asked for it, what the agent did, who approved it, and what happened after — in one place, without reassembling it from five tools.
Closing the loop on one record is the quiet payoff. It’s how “we shipped the thing you asked for” becomes a fact you can trace instead of a claim you hope is true.
The loop, stage by stage
| Stage | Who acts | What happens |
|---|---|---|
| Claim | AI agent | Picks up an assigned task from the shared queue |
| Work | AI agent | Runs over MCP, reads the joined spine for context |
| Ship | AI agent | Opens a PR or deploys, attached to the task |
| Review | Human | Approves or rejects; nothing ships before sign-off |
| Outcome | System | Result recorded on the same task record |
Three of five stages are the agent’s; the decisive ones bracket it — a human assigns, a human approves.
When a copilot is the better fit
The claim-and-ship loop is right for delegated, scoped tasks. It’s overhead for fast, inline help. If you want a suggestion completed as you type in your editor, you want a copilot, not an agent that claims a task and opens a PR. We’re honest about that distinction in AI agents vs copilots in product tools — different tools for different moments, and the loop here is built for the delegated kind.
See the loop
An agent seat is $29/month, across 14 modules, with EU and US data residency. The whole thing — named agents, the MCP spine, review-gated submissions — is browsable read-only, no signup, at platform.aioproductos.com/demo. The mechanics are documented at /product/agents.