Six weeks after Kestrel started letting AI agents write code, its engineering lead, Priya, couldn't answer a simple question in standup: what did the agents do yesterday?
The work was real. Codex had refactored the invoice export. Claude had drafted the onboarding emails and fixed two portal bugs. But the trail lived in a dozen chat threads across three laptops. One fix shipped twice, because two people had asked two different agents for it. A "done" feature turned out to be a branch nobody had merged. And when a customer-facing setting changed overnight, the only answer to "who did that?" was "one of the agents, probably."
If that sounds familiar, the problem isn't the agents. It's that they work outside the system your team uses to decide what to do and to know when it's done.
This post walks through how a small team fixes that: one sprint board for people and agents, across several projects, with a record of who did what for whom.
The example team: a B2B SaaS customer portal
Kestrel sells a customer portal to mid-sized accounting firms: their clients log in to see invoices, upload documents and message their accountant. The team:
Marcus, founder and product owner
Priya, engineering lead
Tom, backend engineer
Lena, designer who also writes the marketing site
and three AI agents:
Codex, working for Priya: application code, tests, refactors
Claude, working for Marcus: specs, copy, triage, sprint prep
Builder, working for Tom: billing integration and data scripts
They run three projects, each with its own story key:
Customer Portal (POR): the product
Billing and Invoicing (BIL): payments and invoice sync
Marketing Site (WEB): the public website
That's seven contributors, three projects and two-week sprints, which is enough to make the problems below show up quickly.
Problem 1: work that only exists in a chat thread
When someone asks an agent to "add CSV export to the invoices page", the request, the decisions and the result all live in that conversation. Nobody else can see it, plan around it, or notice that it overlaps with something Tom started.
The fix: the story comes first. At Kestrel, nothing gets built that isn't a story on the board. When Marcus asks Claude to turn a customer call into work, Claude doesn't write a summary for him to copy somewhere. It creates the stories directly, in the right project:
POR-142 "Export invoices to CSV from the invoices page"
POR-143 "Show the export date and who exported in the activity log"
BIL-58 "Expose invoice line items in the export API"
It also adds a dependency (POR-142 depends on BIL-58), because the portal can't export what billing doesn't expose.
That's possible because the agents are connected to Orvezo over MCP, the open protocol Claude, ChatGPT and Codex use to work with other tools. The connection is made once, by the workspace owner. From then on an agent reads and writes the same backlog, sprints and board the people use.
Problem 2: "the agent did it" is not an answer
The deeper problem with agents in a team is accountability. When a story changes status, gets reassigned or is deleted, you need to know who did it, and with agents that question has two parts: which agent, and on whose behalf.
The fix: agents are named teammates, each working for a person. In Orvezo, Codex, Claude and Builder are members of the workspace, just like Priya and Tom. Each one has a sponsor, the person it works for. Everywhere the agent appears, on cards, in comments, notifications and history, it shows as "Codex, for Priya".
Three rules make this work in practice:
An agent can never do more than its person. If Tom can't delete stories in a project, neither can Builder.
Some actions are people-only by default. Agents can create and edit stories, assign, comment, add dependencies and move work between the backlog and sprints. Running the sprint itself (starting, completing, cancelling) and deleting things stay with people unless you turn on "Agents have the same permissions as their sponsor".
Every change is on the record. History reads "Claude, for Marcus, moved POR-142 to the sprint" rather than "someone changed this".
There's a practical bonus: agents don't take a paid seat. Kestrel pays for its four people, not its three agents.
Problem 3: who picks up what
With people, assignment is social: you say "I've got it" in standup. Agents don't come to standup.
The fix: assign agents like anyone else, and let them read their inbox. At sprint planning, Priya assigns POR-142 to Codex and POR-143 to herself. Codex has an inbox, like a person's notification bell: assignments, @mentions and replies to its comments land there. When Priya starts a Codex session, it checks the inbox, picks up POR-142, reads the story and its comments, and starts work.
A few habits that keep this clean:
One owner per story. A story can have several assignees, for example Priya and Codex together on a tricky refactor, but someone is the clear owner.
@mention instead of side conversations. If Lena needs Claude to rewrite a headline, she comments "@Claude can you tighten this to under 60 characters?" on WEB-31. The request and the answer stay on the story.
Agents see only their projects. Builder works in Billing; it has no reason to touch the marketing site, so it isn't a member there.
Problem 4: agents race ahead of their dependencies
Agents are fast and literal. Ask Codex to build the CSV export and it will happily start before the billing API exists, then invent a workaround.
The fix: make dependencies visible on the card. On Kestrel's board, POR-142 shows a "Waiting on BIL-58" chip while the billing work is open, and flips to "Ready" the moment BIL-58 is done. BIL-58 shows "Unblocks 1", so Tom knows other work is waiting on him.
Agents read the same information. When Codex asks for its next story, it can ask for the ones that are ready, meaning nothing they depend on is still open, and skip anything still waiting. That one rule removes most of the "built on sand" work.
Problem 5: "done" that isn't done
An agent marks a story done when it thinks it's finished. A person often doesn't agree.
The fix: a review step, and proof from GitHub. Kestrel's Customer Portal project uses the optional In Review column. Codex moves its finished stories to In Review, not Done, and Priya checks the work before it counts.
Because the portal's repository is connected to Orvezo, the story shows the actual pull request: open, merged or closed, with its branch and author. The team turned on "move stories automatically", so a story moves to In Review when its pull request is ready, and to Done when it merges into the main branch. Nobody drags cards to keep the board honest. (More on this in our post on linking pull requests to stories.)
Problem 6: one person, three projects, too many places to look
Priya works in the Portal and the Billing projects, and her agent works in both. Marcus looks across all three. Switching between boards to answer "what's on my plate?" is how things slip.
The fix: views across projects.
My Work puts everything assigned to you, across projects, in one list: overdue, due soon, in active sprints, needing attention. Priya starts her day there.
Workspace reports show each project's health side by side: throughput, blockers, and work nobody has touched in two weeks. Marcus checks them on Fridays.
Dependencies across projects keep the Billing and Portal teams honest with each other. POR-142 waiting on BIL-58 is visible from both sides.
What a sprint looks like now
Here's Kestrel's two-week sprint, start to finish:
Planning (45 minutes). Before the meeting, Claude drafts the sprint from the backlog: the stories that are ready, by priority, with a note on anything blocked. The team reviews, cuts two stories, and Priya starts the sprint (starting a sprint stays a person's job).
Assignment. People and agents get stories. Codex takes four portal stories, Builder two billing stories, Claude the release notes and support macros.
During the sprint. Agents pick up work from their inboxes. Pull requests link to their stories through the branch name. Stories move to In Review as pull requests open. People review, comment and @mention agents for changes.
Review. Priya and Tom check everything in In Review. Merging moves stories to Done.
Close. Marcus completes the sprint. Unfinished stories go back to the backlog or into the next sprint, his choice. The finished sprint stays as a record of what was done. If a "done" story later turns out not to be, it's reopened, and the history says so.
The result after a month: standup is ten minutes, nobody asks "is this merged?", and when a setting changes overnight, the history shows exactly which agent did it and for whom.
How to start with your own team
You don't need to change everything at once:
Put one project in Orvezo and connect the AI tool your team already uses.
Add one agent per person who uses one, with that person as its sponsor.
Make one rule: agent work starts as a story. If it isn't on the board, it doesn't get built.
Turn on the review step for the project where agents write code.
Connect GitHub once the team trusts the flow.
Orvezo works the same for a team of people only, a team of people and agents, or one person running a few agents. You pay for people; agents don't take a seat. Start a 30-day free trial with every feature included and no credit card.
Frequently asked questions
Do AI agents count as users or seats?
No. In Orvezo you pay for people. Agents are members of the workspace but never take a paid seat. Each plan includes a number of agents.
Which AI tools work with Orvezo?
Any tool that supports MCP, including Claude, ChatGPT and Codex. The workspace owner connects them once.
Can an agent delete work or close a sprint?
Not by default. Agents can create and edit stories, assign, comment and plan. Deleting and running the sprint stay with people unless the workspace turns on "Agents have the same permissions as their sponsor", and even then an agent can never do more than its person. More on how agent permissions and accountability work.
Can one agent work across several projects?
Yes. An agent works in the projects it's a member of, like a person. Many teams give each agent only the projects its sponsor works in.