Running a greenfield build with agentic engineering from sprint one

Introduction

A small organization needed to move years of operational logic out of a retiring leader's head. Generic software had never fit how the organization worked. After experimenting with spreadsheets, specialized software, and a custom-configured database, it hired Atomic Object to build a custom platform.

Atomic's team ran the project with agentic engineering from the first sprint. The project's most senior developer started the engagement before the Agentic Engineering for Teams framework was published, and the two main developers arrived at many of the same practices on their own. This case study follows the project through the book's process: Definition, Planning, agent partnership and delegation, Review, and Compounding Work. Each section covers how the team ran that part of the process and the conditions that shaped it.

The team

The core team had a delivery lead responsible for product management and coordination, a designer, and two developers. Another designer helped early on, and other Atomic Object team members provided development and QA support.

Both developers arrived with working agentic engineering experience. They needed no ramp time on the basics, but they talked a lot about the details: PR workflow, context boundaries between agents, and what a Linear issue had to contain for an agent to work from it.

The project was planned as nine 2-week sprints. A tenth was added at the end.

Definition: Building the Knowledge Base before the first sprint

The delivery lead and designer started with a 2-week Research, Design, and Planning engagement, Atomic's discovery and framing engagement. They gathered information, ran client sessions, explored designs, and created the Knowledge Base: shared, durable context for people and agents. By the time the developers joined, there was a functioning Knowledge Base, reviewed designs for the first few features, and the client's materials already synthesized into shared context.

The client gave that work an unusual head start. A client stakeholder with an engineering background had written a detailed spec using AI and refined it deliberately. It described the business rules and calculations that had to be right, recurring workflows, and the views that needed to exist. That put the project in High-Precision Spec territory, the book's term for work where the requirements are known and exact before implementation starts. The client had already done much of the work of turning tacit domain knowledge into written form. The senior developer credited the spec, along with the synthesis work before development started, with speeding up the whole team's effort and making subsequent agent work more accurate.

Definition didn't stop when development started. The delivery lead and designer stayed half-time for the first half of the engagement, refining the spec and gathering client feedback on designs for upcoming features while the developers built. The designer dropped to a few hours a week mid-project, then ramped back to about 12 to 17 hours a week in the final month as the work shifted to usability testing and QA.

The Knowledge Base was a set of Markdown files and client-provided artifacts. It held the client spec, meeting transcripts, decisions, and design rationale. Linear tracked what had been built and how; the Knowledge Base recorded why each decision was made.

Planning: Turning feature areas into agent-ready issues

Early on, the team decided not to write a full backlog of user stories up front. With agents moving fast, user stories written at the start of an engagement would be rewritten before anyone acted on them. Instead, the team created large feature areas, called projects in Linear, each with a rough description of what that area of the application needed to do. These formed the feature-level Product Backlog.

Before the first sprint, the team worked with the client to identify the main areas of work and agree on what could be trimmed. Part of the spec was deferred beyond the initial scope.

When a developer picked up a feature area, they worked with Claude and the Knowledge Base to split it into actionable Linear issues on the Work Board, the team's near-term view of work. Those issues were reviewed, refined with teammates if needed, and then handed to the agents. Each time, the developer was doing a lightweight Planning pass: inspecting the relevant code, narrowing the work into an implementation plan, and naming what might break before execution started.

In practice, about 90% of what a feature needed got defined before implementation. The team resolved the rest against working software.

Agent partnership and delegation: The developer's pipeline

The senior developer used two tools in sequence, and each matched one of the book's working modes.

Planning with Claude was an agent partnership: working alongside an agent to think through and critique the approach. The developer and Claude produced an implementation plan for each Linear issue. The plan then went to a validation panel of sub-agents. Some received only the spec; others received the broader project context. Each reviewed it independently for conflicts, edge cases, missing details, and UX problems. The orchestrating agent synthesized their feedback and iterated until the panel reached consensus.

Implementation with Codex was agent delegation: handing off well-defined work and reviewing the output. The developer handed a reviewed plan to Codex, left it running for hours, and came back to pull the output for QA. Database branching in Neon Managed Postgres kept parallel work isolated. Each feature got its own ephemeral branch with its own copy of the database, so agents working on different features never wrote to the same database.

The developer added the validation panel roughly halfway through the project and reported seeing the difference quickly. Issues that used to need several rounds of QA started coming back clean on the first pass, especially UX issues, the category most prone to rework. That freed the developer to run three to four features in parallel.

To limit context switching, the developer staggered those features deliberately: typically, one complex feature with heavy business logic or careful calculations alongside two or three simpler ones, such as CRUD screens or data entry forms. While agents ran on one, the developer reviewed designs and split issues for the next. When one result was ready for QA, another was already in flight.

How much parallel work suits a developer varies. The second developer ran a similar pattern with two features at a time. Both approaches worked.

Review: The team's human quality check

Even while working asynchronously, the team met regularly for Review. The developers, delivery lead, and designer got on a call and clicked through recent work in the running software. The delivery lead and designer caught design gaps. The developers asked questions they'd flagged but hadn't stopped for. The team checked what had been built against what was intended.

Review ran once a week early on and up to three times a week in the final stretch. As agents produced code, these sessions helped the team keep a shared understanding of the product.

A shared agenda in a Slack canvas made the sessions work. When a question came up that wasn't blocking, it went on the running agenda instead of triggering an immediate conversation. Every Review started by working through the list. The senior developer described the value this way: "I can make a sensible default choice now, knowing I have a concrete place to get a real answer from a human already booked and ready to go."

Calendar churn was a real problem. Scheduling Review with developers on multiple client projects required active effort. Toward the end, the senior developer booked three slots a week and canceled the ones the team didn't need.

Client demos ran every 2 weeks, then every week in the final month. The client's reaction to working software fed the next cycle.

Compounding Work: Improving the harness during delivery

The senior developer's pace built up over the project through what the book calls Compounding Work: work that improves the delivery system itself. Stronger specs, better examples, agent instructions, review agents, tooling, and validation paths gave future delegations more to build on.

The developer kept a fifth agent thread running alongside the other four. While a straightforward feature built in the background, a separate session improved the validation scaffolding: adding a reviewer at a particular step, adjusting how the sub-agents were prompted, or refining what consensus meant before a plan could advance. Every new feature became a test of the latest change.

The agent harness, the configured instructions, tools, and checks the agents operated within, changed substantially during the project. By the end, it included a multi-agent planning panel with reviewers working from different levels of context, an automated synthesis loop, and a Codex implementation suite with its own validation layer.

The harness isn't easily transferable. The senior developer's setup runs well for its creator, but getting it to run well for someone who didn't build it takes knowledge transfer the team hasn't yet figured out how to systematize. That work is ongoing.

The outcome

The team managed scope with the client from the start, trimming the initial build and deferring part of the original spec to future work. The client plans to resume development next year.

A client stakeholder came to a late-project demo and could barely contain their enthusiasm. CSV imports from third-party systems were feeding automatically into the application, and calculations were running without manual intervention. It was working the way the stakeholder had imagined.

What to carry forward

Each part of the process had a specific job on this project. Definition gave the agents a Knowledge Base to work from. Planning turned feature areas into issues an agent could act on. Review kept the team familiar with the software as agents produced code, and Compounding Work improved the harness while the product was being built. The client's spec gave the team a head start.

Tech stack

• Frontend: React 19, Vite, TanStack Router, TanStack Query, Tailwind CSS, shadcn.
• Backend: Hono, tRPC, Drizzle ORM.
• Database: Neon Managed Postgres with per-feature database branching.
• Authentication: BetterAuth with TOTP two-factor authentication, role-based access, and disabled public signup.
• Storage: Cloudflare R2 with S3-compatible storage and signed URLs.
• Hosting: Render.
• Observability: Sentry, BetterStack log streaming.
• Testing: Jest, Testing Library, GitHub Actions CI. Integration tests ran against ephemeral Neon branches.
• Project management: Linear.
• Design: Figma with an MCP connector.
• Knowledge Base: Markdown files.
• AI tools: Claude for planning and multi-agent validation; Codex for implementation and validation.