Overview

During each iteration, the team balances multiple pieces of work, each at a different stage. That's why the Definition and Implementation Phases run in parallel. At any moment, the team is defining some features while implementing others. Definition tries to always stay one step ahead, readying what will be built in the next Implementation Phase. Twice a week, the whole team comes together to start and close the work: that shared loop is the iteration One pass through the Planning → definition and implementation → Review loop, running twice per week. , opened by Planning and closed by Review.

One note on Phase order in the graphic below: The team's work on a given iteration opens with Planning. The chapters that follow are numbered differently: Definition first, then Planning, Implementation, and Review. This is because the chapter order traces how a single feature moves from raw intent to shipped software, not how a calendar week runs for the team. The two orders describe the same cycle from different angles; the feature's journey later in this Overview shows how they line up.

Of the four phases, Definition is the one that's new in the agentic era: agents can't read minds, so deciding what to build has to move out of people's heads and onto the page, where an agent can act on it.

That's the whole process. The rest of this chapter describes the same process from a few angles: the rhythm the team runs on, how a feature moves through the process, who does the work, how agents fit in, and what the team never hands off.

The team's weekly rhythm

The iteration cadence is deliberately short. Two iterations a week keeps the development loop tight enough that implementation doesn't outpace comprehension, and imprecise direction surfaces in days, not weeks.

Each cell below shows what the team is doing that half-day, across all the features in flight, not the path of any single feature. When a slot shows Definition + Implementation, the team is splitting up to define some features while implementing others.

Weekly iteration 1: Monday morning Planning through Wednesday morning Review.
Weekly iteration 2: Wednesday afternoon Planning through Friday afternoon Review.

The twice-weekly iteration is for team comprehension. The team plans the next handoff, does the work, and reviews what changed while the context is fresh.

A feature's journey

The iteration needs an initial product shape: enough understanding of users, constraints, and first capabilities for the team and product owner (the person or group accountable for product direction) to sequence the work. At Atomic Object, that early shape comes from a Research, Design, and Planning (RDP) engagement, where teams run discovery and framing work. That starting shape becomes the Product Backlog, the high-level list of capabilities worth making buildable next.

Three other work surfaces keep those Product Backlog Items moving through the iteration. The Work Board holds near-term tasks across the Definition and Implementation Phases, each small enough to finish in an iteration (e.g., a stakeholder session, a transcript to synthesize, a spec revision, a small code change). The Knowledge Base The shared repository of decisions, domain knowledge, examples, and constraints that both the team and agents reference as they work. holds the decisions, domain rules, examples, and constraints Definition and Implementation feed and draw on, kept in the repo where agents can reach it directly. The Specification Repository An evergreen description of how a part of the system or experience works. Kept current with actual behavior; when the team wants a change, the spec is updated first and implementation brings the system into alignment. holds the product, design, and technical specs that describe what to build in enough detail to plan an Implementation and have an agent execute. Specs stay current: when Implementation surfaces constraints or contradictions in the spec, the team updates it to match the actual system behavior.

A worked example

Those work surfaces are easier to see in motion. Here, we will introduce an example which we’ll continue referencing across this resource. Anvil is a B2B collaborative workspace product from a software company we'll call Acme. Anvil's users sign up as an organization, invite their teammates into shared docs and projects, and pay for each member who can edit. Today, every member of an organization can edit everything; Anvil has no read-only access yet.

The Backlog Item Seats & Membership sits on Anvil's Product Backlog: the ability for an organization's admins to control who belongs, who holds a paid editor seat, and how many seats the organization buys. It is a substantial capability that cannot be implemented in a single iteration of work. Before the team can invite view-only members, enforce a seat limit, or cleanly off-board someone, Anvil needs read-only access first: the split between an editor, who holds a paid seat and can change content, and a viewer, who can read without consuming a paid seat.

The diagram below is a mid-iteration snapshot of Seats & Membership. The item has fanned out into Knowledge Base decisions, specs, and tasks on the Work Board. Some of these are ready to build against, some are being built, and some are still being written. The same Backlog Item exists at several resolutions at once.

Active iteration example

1. It starts as a Backlog Item. Seats & Membership is one coarse capability on the Product Backlog, the kind of thing the product owner and team sequence against onboarding, billing, reporting, and admin work. That level of detail is right for prioritizing and wrong for building. An agent handed Seats & Membership would invent a seat model, a role scheme, and an invite flow nobody carefully defined yet, so the capability needs a smaller, explicit target first.
2. Definition makes it buildable. In Phase 1: Definition, the team gathers signal at the level the capability needs, reconciles durable decisions into the Knowledge Base, and turns the next buildable target into the feature spec Invite Members, something agents can execute against without inventing product or architecture decisions. A stakeholder session might clarify that viewer invites are free while editor invites reserve a paid seat. A designer may prototype the invite dialog, Pending row, empty state, and seat-limit behavior. The tech lead may define the email-delivery interface and flag read-only access as a foundation. Those inputs become several specs, starting with Invite Members and the technical spec Email Delivery that Planning can take up next.
3. Planning commits it to an iteration. Phase 2: Planning takes Invite Members and Email Delivery side by side. The team assigns Invite Members as one developer's priority path and Email Delivery to another, and names the risks that need human attention, like two admins inviting into the last available seat or an email that never sends, before an agent writes any code.
4. Implementation builds it. In Phase 3: Implementation, a developer directs agents through the invite flow: shaping the schema, reserving a seat when an editor invite is sent, wiring a pretend email sender that stands in for real delivery, allowing the team to test email features without actually sending them. Implementation hands off the code changes, tests and runtime checks behind it, the known risks, and a broader explanation of the changes to Review.
5. Review checks what landed. Phase 4: Review brings the team back together at the end of the iteration to demo inviting someone as an editor consuming a seat and inviting someone as a viewer staying free. The team probes the edge cases: what if the email never arrives, two admins invite into the last seat at once, or an invite is revoked after someone clicks it? Some findings are quick fixes; others become spec revisions, Knowledge Base updates, or work routed back through Definition and Planning for a later iteration.
6. Each pass feeds the next. The Review Phase activities feed the surfaces that guide the following iteration, so the next pass at Seats & Membership, such as the spec Remove Members, starts with more context than the invite flow had. When Review exposes a recurring drag, such as manually confirming invite emails in the staging environment, the team turns that friction into Compounding Work Work that improves the delivery system itself: stronger specs, better examples, agent instructions, review agents, patterns, tooling, and validation paths that future delegations can build on. : an investment that makes later agent delegation faster and safer, in this case Email Verification Harness, a harness skill and tool that lets agents read the staging mailbox directly.

Who does the work

There are no fixed jobs in this process. People move between the Definition and Implementation Phases as the work demands. Product and business judgment move with them. The same priority, budget, stakeholder, and acceptance tradeoffs shape both kinds of work. When the Implementation Phase stalls for lack of ready specs, the team moves more people into Definition work, or trims the Implementation Phase’s scope until the Definition Phase catches up. When the Definition Phase runs ahead, the team shifts people toward Implementation. Capacity shifts to address the bottleneck.

Partnering with agents

The Definition and Implementation Phases both rely on agents in two distinct modes. Agent delegation Handing off well-defined work to an agent and reviewing the output. Fits core buildout, mechanical hardening, and simple tasks that can be specified clearly. is handing off well-defined work and reviewing the output. Agent partnership Working with an agent as a thinking collaborator — asking questions, pressure-testing plans, explaining what changed, brainstorming gaps. Fits Planning, Review, and human-judgment moments where framing matters. is working with an agent to inspect, critique, explain, pressure-test, or explore a direction before the team commits to it.

For example, in the Definition Phase, the team might delegate transcript cleanup, meeting-note drafting, or formatting a spec from clear source material. It may use agent partnership when reconciling contradictions, pressure-testing acceptance criteria, or deciding what a stakeholder comment implies for a product rule. In Implementation, the team might delegate bounded work, tests, and mechanical hardening. Then they might partner with an agent when shaping a plan, explaining a code change, validating the integrated feature, or probing architectural risk.

Agents multiply the output, but people must still own the discernment. The team and product owner decide what the product should do, what counts as acceptable, how scope, spend, timeline, stakeholder appetite, and reversibility trade off, and whether the change fits the larger product and codebase. Agents can run checks and flag risks. The team decides whether the work is ready to merge, release, or put back into the loop.