Your first Agentic Harness

Every conference stage, every LinkedIn feed, and every strategy deck now carries the same two phrases: agentic AI and the agentic SDLC. Ask the room who has an opinion and every hand goes up. Ask who has personally set one up, run it for a week, and shipped something through it, and the room goes quiet.

That quiet is a leadership problem, not a tooling problem. You cannot steer what you have never operated, and you cannot envision an agentic organisation from someone else's slide. The leaders who set direction in the last platform shifts (cloud, mobile, data) were the ones who had stood the thing up themselves at least once, felt where it resisted, and knew the difference between the demo and the operating model. The agentic shift will be no different.

So this post is a challenge with a handrail. The challenge: stop leading on hearsay. The handrail: a from-zero, end-to-end guide to the same Agentic SDLC our companion post proves in production, where a workforce of one human and three Claude Code seats merged 1,026 pull requests at a 19-minute review median and put a 23-agent platform live in twelve weeks. You will not reproduce those numbers on day one. You will, in about a morning, own the thing those numbers come from: a governed, multi-seat delivery organisation you conduct yourself.

And to be precise about what this is not: it is not vibe coding. Vibe coding is one human, one assistant, and no operating model; it produces demos at speed and unowned code at scale. What you stand up below is the opposite construction: seats with written authority, a board that is the single source of truth, a rule that nobody grades their own work, and gates a seat cannot talk its way past. The speed comes from the governance, not despite it.

The construction you are missing has a name. Craig Suckling, Capgemini's Global Head of Agentic Scale, calls it the enterprise agentic harness: one consistent way to apply context, tools, guardrails, security and standards to every agent an organisation runs, managed as cost per successful outcome rather than cost per token. His frame addresses the agents that run your business processes. This guide applies the same harness discipline one level earlier, to the agents that build your software. Harness the builders first; point it at the business next.

What you are standing up

One paragraph of theory, then hands on keyboards. The Agentic SDLC is an operating model in which a human owner frames the work and owns everything irreversible; a PM seat (a Claude Code session) scopes each work item with acceptance criteria committed before work starts; engineer seats build within that steer; a quality seat independently verifies each delivery against those pre-committed criteria; and a scrum-master seat merges only what quality has passed.

Work flows across a 7-state board that lives in GitHub Projects, and the board is the state: every seat is a pure function of it, so you can close any pane at any moment and lose nothing.

Read that model back against the harness definition and the mapping is one-to-one. Context is the root briefing every session auto-loads, the seat identity files, and the board as single source of truth. Tools are the GitHub coordination bus and the operator commands. Guardrails are the enforcement hooks and the rule that nobody grades their own work. Security is one isolated identity per seat with its own scoped git, GitHub and cloud credentials. Standards are the engineering standard, the spine's 8 invariants, and the learning loop that turns incidents into written rules. Stand this up and you have operated an agentic harness, in miniature, end to end.

The framework itself is public and forkable, open-sourced under Apache-2.0: the same spine (derived from Anthropic's Building Effective Agents), seats, board machinery, and portable rules that run our production build, packaged as a repo you vendor into your own product.

And underneath the machinery sits the idea that makes this an operating model rather than a toolkit: the process and the product run on one spine. The same seven principles govern how the seats deliver (workflow-first; verify against the environment; evaluator is not producer) and how the agents you will eventually ship should behave. The loop you will run below is the spine's eight phases compressed into half an hour: the owner frames, the PM steers, the engineer plans and builds, evals and the quality seat verify, the scrum-master adjudicates and releases, and the lesson gets captured.

What this is, and what it is not

Naming this precisely, because the difference is the offer.

And on the stack: the worked example below is Anthropic and AWS, because that is the pairing our own build runs on, but the framework itself is not AWS-bound. Its hard dependencies are bash, git, GitHub, and Claude; the model can arrive by subscription, API key, or Amazon Bedrock; and the products you build with it can deploy to any cloud. The AWS steps below belong to the example, not to the model.

What this buys your engineering organisation

The leader's reason to run this is the judgment it builds, but the framework earns its keep in an engineering department in four more concrete ways.

Think "standing up a cloud environment"

This is the part every hands-on guide skips and every enterprise stumbles on, because it is organisational rather than technical. Treat it exactly like provisioning a new AWS or Azure environment: three accounts, three credentials, one hour if you have organisational authority, longer if you must ask for it (which is itself a useful discovery about your organisation).

From a bare laptop, in six steps

We assume nothing is installed, not even a package manager. All copy-paste, about 15 minutes. Note what is absent from the list: an IDE. Every seat in this model is a terminal pane; an editor is for the human who wants to read the code, not for the seats that write it.

Step 1: open a terminal

macOS: Cmd-Space, type "Terminal". Windows: PowerShell as administrator, wsl --install, restart, then work inside the Ubuntu terminal it gives you (the framework's scripts are bash). Linux: you know where it is.

Step 2: install Homebrew

$ /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

Step 3: install the tools, plus Claude Code itself

$ brew install git gh node jq   # add awscli for the AWS routes
$ curl -fsSL https://claude.ai/install.sh | bash
# installs Claude Code

That is git (version control), the gh CLI (GitHub from the terminal), Node (the provisioning scripts use it to read the board and label templates), and jq (the bootstrap uses it to wire the enforcement hooks into Claude Code's settings). The bootstrap checks all four before it touches anything, and fails loudly with the fix rather than half-provisioning.

Step 4: tell git who you are

$ git config --global user.name  "Your Name"
$ git config --global user.email "you@company.com"

Step 5: connect GitHub

$ gh auth login -s project     # choose GitHub.com, then "login with a web browser"

The -s project matters: the board your seats route on is a GitHub Project, and the default token cannot create one. Miss it and the bootstrap tells you the fix (gh auth refresh -s project) rather than failing mid-run.

Step 6: sign Claude Code in

Run claude once; the first run walks you through connecting the Anthropic access you chose. On the Bedrock route there is no Anthropic login at all, just two environment variables instead:

$ export CLAUDE_CODE_USE_BEDROCK=1
$ export AWS_PROFILE=<your-sso-profile>

Verify the stack with one line: git --version && gh auth status && claude --version. Nothing exotic; a locked-down corporate laptop that cannot install these has told you something about your agentic readiness that no maturity assessment would.

From zero to a delivery organisation

From here the whole setup is two commands, both shipped in the framework.

Command one: create your product, with the framework inside

You do not need an existing project; this is the moment your product comes into existence. Clone the framework, then point its vendor script at the product you want to create:

$ git clone https://github.com/sebas2810/claude-agentic-sdlc.git \
    ~/Code/agentic-sdlc
$ cd ~/Code/agentic-sdlc
$ bash onboarding/vendor-framework.sh --into ~/Code/my-product \
    --repo <you>/my-product

Starting from nothing, that gives you the shell of a real product: a local repository (created and initialised for you), the framework vendored into agentic-sdlc/ inside it, a root CLAUDE.md stamped (the briefing every Claude session auto-loads), and the first commit published to a new private GitHub repository. Already have a product? Point --into at it and drop --repo. Two details worth knowing: the vendor is staged, so the instance/ overlay in your product is yours alone; and re-running the same command later is the upgrade path, refreshing agentic-sdlc/ in place and never touching your overlay.

Command two: stand up the instance

$ bash agentic-sdlc/onboarding/bootstrap.sh
▶ Agentic SDLC — instance bootstrap
  ✓ sdlc.config written — commit it with the repo
▶ Provisioning GitHub (labels · board · epics · overlay)
▶ Seat Finn (engineer · sonnet) → ~/Code/my-product-finn
  ✓ Instance 'my-product' is live.

The first run is a short wizard: owner, repo, instance name, where the seat checkouts live, which seats to stand up (the default squad is PM, engineer, scrum-master, quality engineer; specialist roles such as cloud architect, data architect and data scientist are available), the git identity the seats commit as, an optional AWS profile, and two yes/no choices (seed the guided first epic; build the macOS apps). One deliberate touch: every seat gets a name, suggested from a pool (Pim, Finn, Cas, Noor, Vera), and everything that belongs to the seat is named after it, from its checkout (~/Code/my-product-finn) to its branch (seat/finn), its routing lane (seat:finn), and its app (Finn.app).

After a single summary and one typed yes, it provisions the entire delivery organisation: the label taxonomy the routing runs on (26 portable labels including the status:* routing index, plus a seat:<name> lane per producer); one Delivery project on GitHub carrying a kanban view for execution and an epics view for steering; four standing epics (maintenance, operations, quality, discovery) so no work is ever orphaned; an isolated git worktree per seat on its own branch, with the seat's identity injected into every Claude session by a session-start hook; the enforcement hooks (no push to main, no AI attribution, rebase before push) wired into the repo's Claude Code settings so the rules are machinery rather than prose; the guided first epic; and a double-clickable launcher per seat, on macOS a real Finn.app, so opening a seat is one click.

Model tiering is built in: judgment seats (PM, quality) default to Claude's capability tier (Opus), volume seats (engineers, scrum-master) to the economy tier (Sonnet), and any seat can be pinned differently with a role:Name:model triple in sdlc.config. This is the harness argument's right-intelligence-per-task principle applied to your delivery seats: route each task to the lowest-cost model that completes it successfully, and manage cost per successful outcome, here per verified and merged story, never cost per token.

Starting a seat

Deliberately unceremonious. Double-click its app, or cd into its worktree and run claude: the launcher titles the window ("Engineer - Finn"), applies the seat's git identity and credentials, and boots Claude Code on the seat's model tier with one standing instruction, which is to confirm who you are, read your briefing and your seat's authority file, fetch main, and idle. A booted seat does nothing until you engage it. And because the seat tooling also ships as a Claude Code plugin, whoever prefers the desktop app or claude.ai/code to a terminal can open the seat's worktree there and have the same seat: same commands, same guard, same injected identity.

The whole operating model, in about 30 minutes

An empty operating model teaches nothing, so the bootstrap seeds a guided first epic ("Hello, Agentic SDLC"): ship a one-page PRODUCT.md stating what your product is, who it is for, and what you are building now. Two small stories, deliberately trivial as software, deliberately complete as process. Every acceptance criterion is pre-committed and falsifiable ("contains exactly these three sections", "no placeholder text", "at most 120 lines"), because the habit being installed is that "done" is decided by criteria written before the work started, not by a model's opinion of its own output.

The board told the whole story; you typed two commands and one decision the entire time. That is the full anatomy of the operating model, experienced in half an hour, on a work item that cannot fail expensively. The second story is the second pass, and the second pass is where the rhythm sets in. Then you close the guided epic and frame your first real one.

How it becomes natural

The muscle memory is genuinely two commands: /board to see the state, /check to advance it (two more exist when you want them: /workload lists a seat's outstanding queue, /backlog the PM's framing queue). A /check is not one item, either: the seat drains its queue, taking an eligible item, doing it, reporting on the issue, taking the next, until nothing remains for its role. Then it reports "queue clear, idle" and stops.

Close every pane mid-loop and resume tomorrow, on another machine if you like, from exactly where the board says you are. The framework had an autonomous self-driving mode once, and deleting it is the companion post's best story; what you are running is the replacement that made velocity go up.

Keeping the installation current is equally undramatic: re-run the vendor script to adopt a newer framework version (it refreshes agentic-sdlc/ in place and never touches your overlay), edit sdlc.config and re-run the bootstrap to change seats or models, and the seat commands update themselves through the plugin. The first-week arc we give new (human) joiners applies unchanged to a leader running all seats solo: day 1, setup and one small steered story; days 2 and 3, a real sub-epic end to end; days 4 and 5, the full loop through verification, adjudication, and staging. By the end of week one, capture your first learned rule into the framework's learning loop. That moment matters more than it looks: once the playbook contains a sentence that came from your incident, it stops being our framework and becomes your operating model.

What operating it teaches you that no deck can

The companion post closes with five questions every organisation should be able to answer before running an agentic workforce. For which work do we have pre-committed, falsifiable definitions of done? Who reviews the AI, and is the reviewer ever the producer? Where exactly are our human touchpoints? What can our agents not do, and is that enforced in code or in hope? What does each agent cost, and who can stop it? Read off a slide, those are a governance checklist. After a week of operating even a one-person instance, they become experiences with names attached: the FAIL verdict you watched, the hook that blocked a push, the touchpoint you felt yourself being (and not being) needed at, the model-tier line in your own bill.

That difference, checklist versus experience, is the entire distance between talking about the agentic SDLC and leading with it. And it compounds: the leader who has operated the loop reads every vendor claim, every internal proposal, and every "we need more autonomy" argument differently, because they have watched bounded autonomy outrun maximum autonomy on their own board.

The honest limits

A fresh instance is the operating model, not the outcome: our production numbers took twelve weeks of real work on a real product, and yours will be yours. The framework is open source under Apache-2.0, so running it, forking it, and taking it to production are yours by right; what the license does not ship is the production judgment behind it, and that is the conversation. The seat apps are macOS-first today, though the scripts themselves run anywhere bash and gh do. And a solo leader running all seats is a lab, not a delivery claim: the point of the lab is the judgment you build, and the two-to-four-person team the Proof of Value post describes is what that judgment buys next.

About the author

Sebastiaan van Wijngaarden

VP, Global AI Growth · Capgemini

Sebastiaan leads global AI growth at Capgemini, working with clients to turn agentic capabilities into business outcomes and to drive AI transformation at scale. He works both ends of that problem: the strategic case for where AI creates value, and the engineering reality of what it takes to build, govern and operate it. This guide is the second kind of work, written down.

He wrote the Agentic SDLC framework it installs, and runs it every day as the operating model behind the 23-agent platform the companion posts describe, built by Capgemini Insights & Data on Claude. He writes about operating agentic delivery in practice, incidents included. Find him on LinkedIn.

Make it real.

© 2026 Capgemini · Insights & Data · The Agentic SDLC series · Framework: Apache-2.0