AGENT NATIVE · TEAM PROGRAM · SIX WEEKS, LIVE ONLINE · ONSITE INTENSIVE AVAILABLE
Twelve sessions, 36 facilitated hours, on your own backlog. Your team learns to specify outcomes, build environments coding agents can work in, verify results independently, and control what an agent can execute. It leaves with a change it shipped through an agent, a workflow that holds its permissions when the model is wrong, and the evidence to decide what to do next.
TEAMS OF 8-16, IN PAIRS · PYTHON AND TYPESCRIPT TRACKS · DELIVERED BY THE AUTHOR OF THE BOOKS
Four team shapes book this program most. Each one arrives with a different problem and leaves with a different first deliverable, so the capstone variant and the transfer tasks are picked per team, not per catalogue.
Today
Every product team builds its own agent loop, tool wrappers and retry logic. Nothing is shared, nothing is observable across teams, and no repository is set up for an agent to work in.
After the program
A repository harness other teams can boot and verify, shared tool contracts with owners, and grader interfaces product teams build on instead of reinventing.
Harness · tools · evaluation
Today
The demo works and production does not. Cost and latency spike, quality regresses silently after a prompt change, and a confident model answer can trigger an action nobody authorised.
After the program
A controlled decision workflow that stays within its permissions when the model is wrong, a protected evaluation set, and a cost per accepted outcome the team can defend.
Policy · evals · economics
Today
Each customer deployment is bespoke. Hand-offs are undocumented and the same integration gets rebuilt for the next account.
After the program
Specification-driven changes with evidence packets, approvals bound to the exact action, and a repeatable pilot pattern for every new account.
Specs · approvals · pilots
Today
Coding agents are used ad hoc, with no policy on what they may touch and no way to tell whether they help beyond a PR count.
After the program
Background coding agents in a bounded issue-to-review workflow, protected release conditions, and a 30, 60 and 90-day adoption plan with named owners.
Delivery · policy · adoption
That is the whole program in one sentence. The differentiator is not a productivity multiplier we cannot prove. It is the quality of the work the team can demonstrate at the end, and every one of these five outcomes is demonstrated live, not asserted.
Two strands, one discipline
Coding agents inside your delivery process, with review gates and evidence.
Discovery, specifications, architecture, coding, debugging, testing, review, migration, release and maintenance.
Agent workflows inside your product, with bounded authority.
Tools, semantic decisions, deterministic policies, context, state, evaluations, security and operations.
Both strands share one engineering discipline: bounded authority and evidence of useful outcomes. The reference project connects them. Your engineers use coding agents to change an application, and the application contains a controlled agent workflow.
Each module is 180 minutes: 15 minutes retrieval and critique, 30 instruction, 15 demonstration, 90 lab, 30 evidence review. The lab changes are small enough to finish in the time. The starter already contains the environment, fixtures and infrastructure, so the session is spent on the engineering decision and its evidence, not on installing a platform.
Choose between ordinary code, a fixed workflow and an agent, set a quality and effort baseline before changing anything, and make a runaway run stop on a budget.
Lab · Establish the baseline
Seeded failure · The model requests the same read tool again and again without reaching the task outcome.
Write a proportionate change specification with acceptance examples and non-goals, and trace every requirement to a test, an implementation task and rollback evidence.
Lab · From ambiguous ticket to executable agreement
Seeded failure · A late constraint contradicts the first plan, and an acceptance test initially verifies the wrong behaviour.
Build a repository entry point and environment an agent can discover, boot, inspect and verify, and turn a recurring architecture rule into a mechanical check.
Lab · Repair the environment, then rerun the agent
Seeded failure · The agent follows a stale build command and imports a prohibited layer despite a prose rule.
Draws on: Agentic Software Factories
Choose between direct functions, CLI tools, MCP and skills for a given integration, and design bounded tool contracts with task-relevant context retrieval.
Lab · Give the agent a reliable verification tool
Seeded failure · A legacy client requests an unsupported extension, and an ambiguous tool argument points at another tenant.
Run a bounded issue-to-review workflow in isolation, with an evidence packet a reviewer can trust and no way for the agent to change its own release conditions.
Lab · Deliver a change with an evidence packet
Seeded failure · The agent tries to disable a failing test, or edit the CI policy, so that its own change passes.
Draws on: Agentic Software Factories
Separate semantic prediction from business logic and authorisation, compare a decision model against a rules baseline, and pick an abstention threshold from held-out evidence.
Lab · A decision model inside a controlled workflow
Seeded failure · A plausible, high-confidence prediction suggests an action the authenticated principal cannot perform.
Tell scaffolding checks, capability evals, regression evals and production monitoring apart, report repeated runs honestly, and protect acceptance evidence from reward hacking.
Lab · Catch a convincing but incorrect success
Seeded failure · The builder learns the visible tests, weakens one assertion and persuades an uncalibrated judge to approve.
Resume a workflow without repeating consequential effects, and design approval expiry, reconciliation and deletion behaviour across a restart.
Lab · Crash after the effect
Seeded failure · A timeout leaves it unknown whether a credit was committed, and the next run also finds an expired approval.
Draws on: Agentic SaaS Playbook in 2026
Threat-model data and authority across the whole tool path, and enforce action constraints independently of prompts and model-based detection.
Lab · Keep the useful action; block the injected one
Seeded failure · A valid approval is replayed for altered arguments, and a forged tool result claims elevated privileges.
Draws on: OpenClaw Agents: Automate and Scale Operations
Choose single-agent, parallel-worker or coordinator patterns from measured need, bound aggregate spend, and prove whether an extra agent earns its cost.
Lab · Prove that the extra agent earns its cost
Seeded failure · Parallel workers each assume they own the full budget and propose conflicting edits to the same file.
Design a staged rollout with stop conditions, measure team outcomes without mistaking generated code or token use for productivity, and assign enduring ownership.
Lab · Make the launch decision
Seeded failure · PR counts double while review queues and escaped defects grow, and a moving model alias changes behaviour.
Draws on: AgentOps: The Playbook For Businesses
Deliver a bounded change through a documented agent workflow with independent acceptance evidence, defend a decision boundary against an unseen failure, and hand over a pilot plan.
Lab · Ship the evidence, defend the decisions
Seeded failure · The assessor picks an unseen combination of authorisation, stale context, changed spec or partial failure.
The six weeks
Two modules a week, then one application to the team's own work before the next pair.
Capstone
A team chooses one variant before the program starts. All four keep the same verification and authority standard. Company code is welcome but optional: the reference project is a valid substitute when access restrictions would slow the team down. In session twelve the team demonstrates the change and the workflow, answers an unseen challenge without weakening its protected acceptance criteria, and every engineer explains one decision and diagnoses an unfamiliar trace.
Session twelve runs as 15 minutes briefing, 90 challenge work, 45 demonstrations and defences, 30 handover. With more than four capstone teams we add an assessment session or a second assessor.
Four variants, one standard
Product feature
Product engineering
Specify and deliver a real feature, verify its user behaviour, and exercise the reference controlled workflow.
Brownfield repair or migration
Platform and mature application teams
Characterise existing behaviour, make a bounded change, and demonstrate compatibility and rollback.
Agent application
Teams shipping agent features
Implement a useful tool or decision workflow with evaluation, authority checks and recovery, and show how coding agents delivered a change.
Delivery automation
Teams without an AI product
Classify or triage change requests while deterministic policy owns protected paths, permissions and release decisions.
The flagship is the program. The two shorter formats exist for teams that need a start now, and each states exactly what it does and does not cover. All three are scoped and quoted per cohort after an intake call, not per seat.
36h
THE PROGRAM6 WEEKS, 12 SESSIONS, 36 FACILITATED HOURS
Twelve 180-minute sessions over six weeks, two a week, so the team applies each week's modules to its own work before the next session. Every session is short instruction, a long lab, and a review of the evidence the lab produced.
FORMAT
8-16 ENGINEERS, WORKING IN PAIRS · LIVE ONLINE, YOUR TIMEZONE
Honest outcome
All twelve modules, the team capstone and an individual defence for every engineer.
Quoted per cohort · Invoice on booking · PO accepted
18h
3 CONSECUTIVE DAYS, 18 FACILITATED HOURS
Three consecutive days at your office, 18 facilitated hours. It covers the accelerator's four blocks, adds the recovery and security labs, and ends with a supervised change from your own backlog. The full competency assessment needs additional application time afterwards.
FORMAT
8-16 ENGINEERS, WORKING IN PAIRS · AT YOUR OFFICE
Honest outcome
The accelerator plus deeper recovery and security work and a supervised backlog change. Additional application time is required for the full competency assessment.
Quoted per cohort · Invoice on booking · PO accepted
12h
12 FACILITATED HOURS, FOUR BLOCKS
Twelve facilitated hours in four blocks: baseline plus specification, harness plus independent verification, deterministic policy plus the semantic-decision comparison, and bounded delivery plus a pilot decision. It uses substantial scaffolding and does not cover the full flagship competencies.
FORMAT
8-16 ENGINEERS, WORKING IN PAIRS · LIVE ONLINE, YOUR TIMEZONE
Honest outcome
A specification, a repository harness improvement, a controlled workflow exercise and a baseline plus pilot proposal, with substantial scaffolding.
Quoted per cohort · Invoice on booking · PO accepted
SIX-WEEK TEAM PROGRAM
36 facilitated hours
6 weeks, 12 sessions, 36 facilitated hours
ONSITE INTENSIVE
18 facilitated hours
3 consecutive days, 18 facilitated hours
TEAM ACCELERATOR
12 facilitated hours
12 facilitated hours, four blocks
90 MINUTES
Decisions on task selection, ownership, review capacity, investment and the evidence a rollout should produce. For the leaders who will sponsor the program, or for a leadership team that has to decide what to fund.
Before a program, or on its own
6-12 ADDITIONAL FACILITATED HOURS
Chosen after intake: identity integration, fleet migrations, evidence retention or organisation-specific governance. Extends the flagship for teams inside a defined trust boundary.
Added to the flagship program
Headcounts are planning heuristics. Risk, coupling, existing platform capability and review capacity matter more than organisation size. A startup may simplify infrastructure; it does not get to skip authorisation, independent verification or accountability. Enterprise requirements are an extension of the same executable controls.
Each dimension is scored 0-4: absent, asserted, partly demonstrated, demonstrated and reproducible in the stated environment, or demonstrated under the assessment challenge with clear limits and maintenance ownership.
Pass rule
A pass is 75 out of 100, with at least 3 of 4 in independent verification and in policy and security, and a successful individual defence. Tampering with protected acceptance criteria, unauthorised execution or fabricated evidence is a critical failure regardless of the average. Remediation and reassessment are available.
What the credential says
The credential says demonstrated course competencies. It does not claim production certification, professional licensure or a measured improvement in your business results.
Evidence modes
Every result is labelled with its evidence mode: deterministic contract and replay, live task evaluation, independent behavioural check, or limited production observation. Fixture-only participation earns completion evidence; the full competency credential needs a supervised live coding-agent task and independent functional evidence.
Pre-work is about three hours per engineer. The six-week team program adds 12-18 hours of application to the team's own work between sessions; that application is where the transfer happens, so it is scheduled, not hoped for.
30 minutes with the engineering lead. We confirm the team, the format, candidate dates, the capstone variant and what should be true 90 days after the program. You get a written proposal within one business day.
About three hours per participant: an environment check, Git, testing and agent-loop vocabulary, data and provider constraints, and one candidate change from the backlog. A short foundation bridge is offered to engineers without model or API experience.
Twelve 180-minute sessions over six weeks, two a week. Each one is 15 minutes of retrieval and critique, 30 of instruction, 15 of demonstration, 90 of lab and 30 of evidence review. Between sessions the team applies the modules to its own work, 12-18 hours in total.
Session twelve. The team demonstrates its change and workflow, answers an unseen challenge without weakening its protected acceptance criteria, and every engineer defends one decision and diagnoses an unfamiliar trace. Scored against the published rubric.
Decision reviews after the last session: continue, narrow or stop the pilot at day 30; expand only if quality and operational burden hold at day 60; continue, change or retire the investment at day 90.
Decisions after the program
Proposed follow-up reviews. Each one looks for specific evidence and ends in a decision, including the decision to stop.
Each elective has an entry condition. If the team does not meet it, the elective is not sold. An emerging topic becomes a core requirement only when it solves a recurring learner problem, can be evaluated, has a usable fallback and can be taught in the time available.
Entry · Residency, offline or volume requirement
Outcome · A local-versus-hosted quality and total-cost comparison
Entry · A real independent-agent boundary
Outcome · A versioned interaction contract with authentication and failure handling
Entry · Large tool catalogue or expensive intermediate context
Outcome · Measured benefit while preserving sandbox and authorisation boundaries
Entry · Existing identity and policy architecture
Outcome · A runtime control map and an experimentally validated adapter
Entry · Existing service inventory and lineage
Outcome · A scoped rollout with dependency-aware verification
Entry · Stable evals and protected policies
Outcome · A proposed harness change evaluated on untouched cases and reviewed before adoption
Engineering teams inside companies, from startups to enterprises, that are shipping with coding agents, shipping agent features, or about to do both: platform teams, AI product teams, forward-deployed and solutions teams, internal tooling teams and the CTO office. It is company-sponsored team training. We do not run open-enrolment cohorts for individuals.
Five things it can demonstrate: a real change driven from a reviewed specification through a coding agent with independent acceptance checks; a repository environment agents can discover, boot, inspect and verify; a controlled decision workflow that stays within its permissions when the model is wrong; a protected evaluation set with evidence for quality, failures, review burden and cost; and a bounded pilot proposal with owners, rollback and 30, 60 and 90-day decisions.
No machine-learning background is assumed. Participants should be able to read and modify a small service and use Git and tests. Engineers without model or API experience get a short foundation bridge before session one. Labs run in Python and TypeScript, and the team picks its track.
The six-week program is the full curriculum: twelve modules, the team capstone and an individual defence, applied to your own backlog week by week. The onsite intensive is three days at your office: the accelerator's four blocks plus the recovery and security labs and a supervised change from your backlog, with the full competency assessment completed through additional application time. The team accelerator is twelve facilitated hours in four blocks with substantial scaffolding; it produces a specification, a harness improvement, a controlled workflow exercise and a pilot proposal, and it is deliberately not sold as covering the flagship competencies.
Eight to sixteen engineers, in pairs, with a second facilitator above eight. Pairs rotate driver, reviewer and incident-diagnosis roles, and every learner has to explain and challenge an agent's work rather than submit its output. Materials are keyboard-accessible, sessions have captions and transcripts, and there are alternatives to live camera participation.
Your code is welcome and optional. The capstone has four variants, chosen before the program: a product feature, a brownfield repair or migration, an agent application, or delivery automation for teams whose product contains no AI. Labs run on a reference project, a small SaaS service with tickets, tenant-scoped users and a credit ledger, and the reference project is a valid capstone substitute when access restrictions would slow the team down. Work on your own systems stays in your environment, under NDA.
The capstone is scored 0-4 on seven weighted dimensions: specification and traceability, harness and reviewable delivery, independent verification, policy and security, recovery and state, operations and economics, and individual understanding. A pass is 75 of 100 with at least 3 of 4 in independent verification and in policy and security, plus a successful individual defence. The credential says demonstrated course competencies. It does not claim production certification, licensure or a measured business result.
We do not make that claim, because the evidence does not support it. The program teaches the team to measure what matters: accepted outcomes, review and correction effort, rework, escaped defects, unauthorised-action attempts, and all-in cost per accepted outcome including failed attempts. A no-change decision can be the right result, and the day 30, 60 and 90 reviews are designed to tell you honestly whether to continue.
The curriculum was refreshed against public engineering accounts and specifications with a research cutoff of 26 September 2026: the final MCP release of 28 July 2026, the 2026 OWASP LLM and agentic resources, Spec Kit, OpenSpec and Kiro, and Jev as the current case study for semantic decisions inside deterministic control flow. Every module and source has an owner, there is a monthly editorial review, and a technical freeze at least 14 days before each delivery pins a runnable release with a change log.
Pricing is per cohort, not per seat, and is quoted after the intake call in EUR plus VAT where applicable. We invoice on booking and accept purchase orders. Travel for the onsite intensive is billed at cost.
A 90-minute leadership briefing covers task selection, ownership, review capacity, investment and rollout evidence, before a program or on its own. An enterprise extension adds six to twelve facilitated hours after intake for identity integration, fleet migrations, evidence retention or organisation-specific governance. After the program, the Software Factory builds and runs agent workflows with your team, and the pilot proposal is scoped so it can pick that up.
The more you say about what the team is building, which capstone variant fits, and what should be true 90 days after the program, the more specific the proposal. Three lines is enough to start.
What happens after you submit
Prefer to talk first? Book an intake call.
Ready when your team is
Request a proposal and we will come back with dates, a format recommendation and a capstone suggestion. Or book a call and we will tell you straight if a program is not the right next step.