The first agent on a team is a personal productivity story. The fifth is an organizational one. Somewhere between those two, a group stops being a team that uses AI and becomes an agentic team: humans and agents working the same board, on the same tasks, under rules someone had to write down.
That transition is where most of the interesting questions live. Who owns work an agent executed? What does a standup contain when the board updates itself? How many agents can one reviewer absorb? This guide covers the composition of an agentic team, the division of labor that survives contact with real work, and the working agreements worth stealing. Sharkly is the platform we build for this shape of team, and the failure modes below come from watching the shape go wrong.
TL;DR
An agentic team is a group where people and AI agents both hold assigned work in one shared system, with humans keeping direction, authority, and acceptance. Agents research, execute, test, and report. People set direction, grant authority, and accept the result. The practical requirements are a task record both can read, an execution assignee separate from the responsible person, a review state that reaches someone, and enough written scope that an agent does not have to guess.
What an agentic team is made of
Three kinds of participant, and it helps to name them precisely.
People create and update tasks, comment, receive queue items, get assigned work, review agent results, and manage settings their role permits. They are the only participants who can be accountable.
Agents are saved working configurations rather than one-off prompts: instructions, a runtime such as Claude Code or Codex, repositories, environment, run settings, and bound skills. An agent is closer to a documented role than to a person. Our Sharkly Agents explainer covers what goes into one.
Crews group agents under one leader agent for work that needs coordination. Execution is leader-first: the leader reads the task and the crew instructions, then either handles the work or brings in specific members. That ordering exists to stop every member starting at once. The details are in our guide to Sharkly Crews.
Access is layered on top: an organization role decides broad administrative capability, and space membership decides which work areas someone can reach. Agents get scoped the same way, to specific repositories and specific machines.
The division of labor that works
Sharkly’s own contract is a good default because it is narrow enough to enforce: agents research, execute, test, and report; people set direction, grant authority, and accept the result.
Four responsibilities stay with humans no matter how capable the agents get.
- Direction. Deciding what is worth doing and in what order.
- Context. Writing scope an agent can act on: why the work matters, what is out of scope, relevant files and constraints, and how completion will be reviewed.
- Acceptance. Reading the evidence and deciding the work is done. A finished run is not an accepted outcome.
- Escalation. Deciding what happens when an agent is blocked, wrong, or has hit a question that needs judgment.
Everything else is negotiable and depends on how much your team trusts a given agent’s track record on a given kind of work.
How work moves through the team
The loop is short and worth making explicit, because teams that skip a step feel it within a week.
- A person writes a task with a stated outcome and acceptance criteria.
- The task gets a human assignee for responsibility and an agent or crew as execution assignee. These are separate fields, and changing one does not change the other.
- Moving the task out of a parked backlog state starts the run when the assigned agent is ready.
- The run executes on a connected machine, in an isolated directory, with progress and blockers returning to the task.
- The agent leaves the work waiting for human reply or waiting for human review, which lands in the responsible person’s agent inbox.
- A person reads the trace and the diff, then accepts, comments to continue, or reassigns.
Comments are the durable conversation. A comment on a task with a ready agent can enqueue the next run, which makes review feedback and execution the same motion instead of two systems.
Three shapes that work
The paired developer. Each developer keeps one or two agents for their own recurring work: test coverage, dependency bumps, refactors they have done twenty times. The team benefit is that those agent definitions are shared, so a new hire inherits five working setups on day one instead of building their own.
The squad with a shared crew. One crew handles a category of work the whole squad depends on, such as release preparation or incident triage. A leader agent decides which member contributes, and one human owns the category. This is the shape that scales furthest before review capacity binds.
The platform team standardizing. A platform or developer experience group owns the agent definitions, skills, and machine configuration for several product teams. Product teams assign work; the platform team keeps the runtimes, permissions, and instructions current. This shape trades some autonomy for consistency, and it is usually the right trade past about thirty engineers.
None of the three requires reorganizing anything. They are patterns for who owns the agent configuration, which is the question that decides whether agent capability compounds across the team or stays personal.
Working agreements worth adopting
One accountable human per task. Even when a crew of four agents does the work. Especially then.
Scope gets written before assignment. If nobody can say how the result will be checked, the task is not ready for an agent. This rule alone removes most bad runs.
Review is scheduled capacity, not spare time. Decide how much agent work each reviewer can absorb per day and hold the number. A growing pile of unreviewed agent results is the same debt as unmerged pull requests, and it grows faster.
Failed runs get diagnosed, not retried. Open the execution log and read the title and technical details first. Vendor errors that look alike often need opposite fixes, so a reflex retry hides the real cause.
Agent definitions get an owner and a review date. Instructions rot. The developer who wrote the migration agent leaves, the conventions change, and the agent keeps confidently applying last quarter’s rules.
What breaks first as the team grows
Review capacity goes first, every time. The second constraint is machine capacity: runs queue while waiting for concurrency or a free working directory, and a team that added agents without adding computers discovers a queue it cannot see from the board.
The third is ownership drift. When several agents contribute to related tasks and nobody renames the owner after a handoff, you end up with work that is technically assigned and practically unowned. A weekly pass over tasks with agent assignees and stale human owners takes ten minutes and prevents the messy version of this. If you would rather start from a system that already separates these fields, download Sharkly and run one repeating kind of work through it for a week.
FAQ
How many agents per developer is reasonable? Start at one or two and let review throughput set the ceiling. The right number is the one where results do not wait longer than a working day for a human decision.
Do agents attend standup? Their work does. The board carries status, so standup becomes the exception list: failures, blocked runs, and results waiting on people.
Should an agent ever be the only assignee? No. Keep a person responsible for the outcome, with the agent in the execution slot. Our guide to AI agent project management explains why that separation matters more as volume grows.
How do we onboard a new agent to the team? The same way you onboard a person: give it a narrow first assignment, review closely, then widen scope. Save what worked as the agent’s instructions and skills so the next team does not rediscover it.
