This is the operating model for Frontier Development. The article Introducing Frontier Development provides the introduction. These pages contain the detail required to implement and run the model.
- Three Streams — where Frontier Development fits alongside Agile and AI Organisations
- Metrics — Time Built and the six bias guards
- Roles — Engineering Leader, Skilled Engineer, selection, secondment
The bubble
The bubble comprises an Engineering Leader, a Skilled Engineer and their Agentic Workforce. It’s impermanent by design — formed around a clear intent, output and metrics. Then disbanded after task completion.
The Engineering Leader brings intent, judgment, architecture, and is responsible for the Execution Plan. They are primary owners of the Forming and Storming stages.
The Skilled Engineer brings Engineering process and operational knowledge and are responsible for the Production Plan. They are primary owners of the Norming stage, and the handover to their delivery team in the Performing stage.
The stage lead flips the RACI model, so where the Engineering Leader starts out Responsible, then end up Consulted. The Skilled Engineer starts out Consulted and ends up Responsible. There’s a part in the middle where both are Responsible at the same time - it’s up to the pair to decide when to transfer to responsibility.
Frontier Governance layer
There should be a periodic review meetings to assess: in-flight bubbles; performance of completed work; and consider new Frontier Development candidates for prioritisation.
Skilled Engineer selection criteria and secondment mechanics are covered in /development/roles/.
Who’s on the Governance Team
The Governance team comprises business and technical representatives who are responsible for establishing selection criteria, discovering and assessing candidates for Frontier Development initiatives. There is also an SLT representative that sits within this team.
In practice, a company implementing Frontier Development would want to create the right balance, but the suggested composition is:
-
Head of Engineering - Accountable Owner of Frontier Development, forming the governance team, and ensuring this team follows the process and are compliant against all of their responsibilities. Responsible for new initiative discovery, and resolving any ties ahead of reporting up to the C-level. This individual can be considered as Engineering Leader candidate for bubbles.
-
Head of CX and/or Head of Operations - Responsible for new initiative discovery.
-
SLT representative - Responsible for representing C-level within any decision making. Also a member of the steerco. If this member is Technical e.g. CTO/CIO, the this individual can be considered as Engineering Leader candidate for bubbles.
-
Principal/Staff Engineers - Responsible for new initiative discovery and resolving any unknowns/blockers ahead of the bubble being formed. Responsible for taking on bubble ownership as Engineering Lead role once the initiative is approved.
-
Senior CX/Ops Staff - Responsible for new initiative discovery and resolving any unknowns/blockers ahead of the bubble being formed. Consulted by bubble once initiative is approved.
Depending on the size of your org, engaging all of these individuals into the governance team may risk slowing down decision making. If your Engineering leadership and CX/Ops staff is too large, then the Heads should be considering who are the best representatives. Ideally, Engineering, CX & Ops staff should be max two per business unit and all should be contributing to the discussions. Engineering needs special consideration though.
Principal/Staff Engineers along with the more senior Technical reps in the governance team are also available for Frontier Development assignment. That means that this team is self-limiting on number of concurrent bubbles i.e. 3-4. If you wish to expand past this soft limit, these Engineering staff can be rotated through the governance team, dropping out of the team and reporting up when they are actively involved in a bubble. Similar approaches can be considered for CX and Ops staff, as it provides wider opportunity for learning and career growth.
As mentioned earlier, the C-level representative in the governance team aids with alignment to C-level goals, so that steerco sessions are raising less surprises and more productive discussions and challenges. The Frontier Governance team should hold regular steering sessions with Steerco e.g. monthly. The purpose of Steerco is to hold the the Governance team accountable - they should be able to understand the benefits of each bubble, but their primary interest should be in the sum of the product. Not to say, they won’t have their own interests they want addresses, but there should be enough trust in the process, that this will be handled once due diligence is done, and the right bubble is ready to be formed.
The Agile Delivery Lead / Traffic Manager is at minimum, a role consulted and informed by the governance team, not a role within the governance team. Instead this role should be present and contributing at the steerco.
Reviewing in-flight Bubbles
Bad news should travel fast: The bubble should escalate blockers or blow-outs as soon as sure (or unsure) enough. If they are able to continue execution, while waiting on the response from the governance team, then they should continue to do so.
The governance team should review this escalation and decides if its significant enough to stop, or if there is an alternate approach that should be avoid this. If a bubble is wound down, the living document must be retained, not deleted. Documentation outlives tenure, and with AI-enabled knowledge base RAG (Retrieval Augmented Generation), future discovery of these past attempts should help to learn from past blockers.
Reporting Bubble Progress to Steerco
The governance team should regularly report the following to Steerco:
- Intent, output and target metrics of shortlisted bubbles
- Progress of in-flight bubbles
- Performance of past bubbles
The governance team should have a clear definition agreed with steerco, on what constitutes an idea for a bubble. To enable an effective governance team, steerco should be cautious of being too biased on governance selection. Rather if steerco have a candidate they want to be reviewed, the governance team will complete their due diligence, and prioritise at their earliest convenience.
Stage model
Forming — The Spike
Before the bubble is formed, the Engineering Leader will have been involved with discussions of intent and output within the governance layer, and part of the approval process for this bubble to be formed in the first place.
As the bubble is forming, the Engineering Leader then spends time with their agentic workforce to draft the Execution Plan which focuses on feasibility and CX. The Engineering Leader may wish to prove out some initial spikes. No unit tests or any other hardening are required at this stage to ensure any pivots or refactoring is not time consuming for the agents.
The governance team identify a Skilled Engineer to join the bubble. It’s best to keep an up-to-date volunteer register, rather than be forced into an unwilling partnership. As Skilled Engineers are seconded from their delivery team, no more than one Engineer can be seconded from a team at any one time, so as to minimise the disruption to the team.
At some stage in the forming stage, the Engineering Leader leads a kick-off with the Skilled Engineer, to discuss the intent, the output, and a walk-through of the Execution Plan. The Skilled Engineer can give feedback in the moment, as well as review and give feedback after the kick-off.
Storming — Generative Build
The Engineering Leader may have already got a head start with their agents to complete some spikes or build out a POC, but this is the first phase where the Skilled Engineer is likely to get hands-on with the generative build. The Execution Plan is set, and ready to be taken on by the agentic workforce.
If both Engineering Leader and Skilled Engineer are eager to do so and the work splits neatly into separate concerns (and ideally separate repos and CI) then divide and conquer can work well. Frontend vs backend is a obvious example where the logical separator is the API.
If both intend to work on the same codebase, special care must be taken not to work on the same areas of code, otherwise all time gained in agentic development will be lost in resolving merge conflicts. Agentic instructions can help to ringfence no-go zones.
Otherwise, it’s better to assign a primary on the code, where the secondary is making small tweaks only. Or tag team on the work, if both want to task their agents to make some wholesale changes.
At some stage after bubble selection and the Skilled Engineer confirming understanding of the intent and output, there is a feedback loop from the Skilled Engineer to their delivery team. This first checkpoint can happen any time during Storming, but must be done before Norming.
Norming — Hardening
Bubble works on the Production Plan; Skilled Engineer is Production Plan owner, as they are the operational SME, and sometimes the way a leader thinks things work, is not always the way they actually work.
The Production Plan determines the phases required to complete hardening, and every phase completed then needs to be kept compliant from that point on.
For example, the first phase should focus on code coverage. Achieving 100% for both unit and system tests are feasible, if working on a Greenfields initiative. As for brownfields - leaving something in a better state than you found it, is a good motto. Once these targets are met, then all remaining edits should keep this coverage percentage.
Now that the test coverage is in place, its much easier to focus on topics like infrastructure, security, observability, monitoring and alerting. Phases of the Production Plan are best determined by the needs of the organisation. It will be tempting to create a standard before the first bubble is formed, but unless there’s already a rigid set of practices (or even agent skills), instead of boiling the ocean, its better to let the Bubbles iteratively build up these standards as each one tackles a new problem, unique in its own way, and these standards are better enforced by agent skills, rather than static documentation.
The Production Plan highlights all the concerns that should not be addressed in the Execution Plan. Focusing on Production Plan elements too soon means the Execution Plan agentic workforce is spending too much time ensuring compliance, rather than focusing on functionality. Best case, you are waiting longer for your agents to respond, worst case it’s an agentic cost blowout.
Performing — Definition of Done
The primary focus of the bubble during Performing, is to monitor performance metrics and feedback from the end users, handle any critical amendments, as well as ensure the Skilled Engineer’s delivery team has sufficient handover.
Once this warranty period is deemed to be over, the bubble is burst. It is important that this warranty period doesn’t continue too long (one week should suffice), but its also important that the Engineering Leader is focused on measuring results to present back to the governance team, including any dashboards, so that continued performance can be monitored long after the bubble is burst.
Any change management that is required after this, can be requested to the Frontier Development governance team for prioritisation, or if large enough, back to the agile process.
Living document mechanics
Compared to Agile epics, stories and tasks, Frontier Development agents move much faster, and considering they are executing on a code base, containing all this information in a single place aids with that speed.1
All working documentation of the bubble should be maintained within the code repository. A dedicated docs/ folder is useful, and any changes to these docs are reviewed and committed like code changes.
These documents should be explicit about HOW the problem is solved, not just WHAT is being solved. This ensures the business and technical language stays in the one place, ensuring the solution never strays far from the problem. Documents must stays mutable and can pivot mid-execution if unexpected findings surface. Making adjustments to the documents then make it easier for the agentic workforce to review the changes, and propose amendment plans to the code, before commencing execution.
Markdown format is best because its readable by humans and agents equally. Any other external source documents like pdfs can also be stored in this location too, although some agentic models take more effort to read proprietary formats, so consider translating them to a format more easily consumed.
The Execution Plan and Production Plan should be structured in large Phases and smaller Steps. The agents responsibility is to take the intent and knowledge of the humans, discuss the options, and then extract it into an execution sequence. Human’s must review each Plan, and approve the inference and the sequence. Agent time estimates can also be generated as part of the document - as with human estimates, a large AI estimate might be cause for pause and questioning about the inference of the AI. The AI can also prepare estimates for comparative human-coded estimates, although this might be a distraction up front, and just as easy to do at the end of the project, when reporting metrics back to governance and steerco.
The executing agents can then review that discrete step in terms of the larger plan, and the human can review the output of that step. Compared to Agile, that step and the pull request, might comprise a significantly larger code diff then generated by a human developer, but the code review is not specifically focused on the code changed, rather the description of the changes performed. Anyone concerns about AI describing its own work for review, should also consider its relatively easy for a human to make mistakes when documenting their own changes, or push “one more commit” to fix something unrelated to the PR.
If a bubble is ever prematurely disbanded due to an unresolvable issue, this repos and its shelved documents should be retained for institutional memory and future RAG discoverability.
Execution Plan vs Production Plan split
Execution Plan
The Execution Plan is a focus on feasibility - a gap analysis on what we currently do vs what we need to do to turn the intent into an outcome. An Execution Plan should have strong focus on CX improvements. This is no longer an MVP solution that gives the end user just enough controls to tick the box ahead of product launch. Rather its replacing poor process with process excellence.
Compliance with Definition of Done / Ways of Working is deliberately excluded as the focus is on proving the problem can be solved, rather than ensuring it meets minimum operational standards. Prematurely tackling these tasks will result in agentic cost blowout, where each agentic run, spend more time on maintaining compliance instead of implementing the functional change.2
That said, the execution plan should not put anything into production, except for controlled and communicated A/B tests.
Production Plan
The Production Plan is a focus on hardening - every checkbox ticked, and any minimum standards exceed well beyond the means of a human-only workforce. It ensures the solution the bubble produces is secure, reliable, observable, monitored, and easy to maintain for future iterations. Its best to start with test coverage, so that the next iterations of the Production Plan have the safe guards in place to ensures that nothing is functionally broken on each pass. After that the order of phases is more down to the path of least resistance. For example if approvals are going to be needed to productionise, then its best to plan for those approvals up front, then pivot to other phases while that RFC is being considered.
An organisation just starting with Frontier Development, might be tempted to start with a reusable and detailed Production Plan template, but the work handled by Frontier Development will be very broad, with both internal and external facing solutions, and no two plans will look the same.
Instead each bubble should contribute back to a centralised Production Plan template. Re-useable Agentic skills are the most obvious ways to shape these contribution, although these should be scoped and documented to in the assumption that they fulfill a very specific problem, because the next problem might be shaped in a different way.
Each phase completed must be kept compliant from that point on, meaning that each time a new phase is completed, all previous phases must pass.
For example, if the first phase is 100% code coverage; all subsequent phases must maintain 100% coverage. If the second phase is an application security review, then it must be done, maintaining the 100% code coverage target and further phases must not introduce new security flaws.
Execution vs Production Plans
The only things that combines these two plans are the intent and outcome. Everything everything else is mutually exclusive. As per the Living Document mechanics, Execution Plan and Production Plan both live in the repo as markdown, version-controlled alongside code, so the agents are able to consider both documents within their context window.
Quality gates
There are checkpoints between Forming, Storming and Norming, but no quality gates. The quality gate sits between Norming and Performing and this is due to the production release. These quality gates are org and scope dependent.
The first check is that the Production Plan plan has completed. There may be reported metrics all passing minimum requirements, such as code coverage, SecOps and their CI tools as well as delivery and ops team hand-overs.
If these release is customer-facing, you might have release management / go-to-market check gates to complete. This is likely outside the expertise of the bubble, and so the relevant departments should be briefed in to complete End to End checks.3
Frontier Governance also have their quality gates - they require that the performance dashboards are in place, ready to measure the ROI through the Time metrics (if its traffic-dependent) as well as the bias guards documented in /development/metrics/.
Operational notes
Role coverage: not excluded by title — excluded by dedicated headcount; a PM or BA by title may be a subject matter expert and should be consulted as such; Engineering Leader performs PM duties; Engineering Leader and Skilled Engineer both perform BA duties; if the work genuinely needs a full-time PM or BA, it belongs in Agile, not Frontier Development.
Task granularity: no fixed guideline — judgment call based on confidence and work type; high confidence, well-defined output → longer runs (overnight if warranted); iterative CX or uncertain territory → shorter runs to catch drift and prevent waste; control mechanism, not a rule.
Communication defaults: set each other as VIPs on messaging platform; aim to turn around Q&A as quickly as possible; if discussion needs face-to-face, switch to real-time immediately rather than scheduling a meeting later.
-
I’ve avoided Agile language here because the work-rate of an Agentic Workforce is not comparable to the effort of a human developer, so multiple Epics are completed within a day, user stories and their story points are replaced with semantic reasoning and holistic intent, and tasks are one-line foot notes. ↩︎
-
“Agentic cost blowout” might lack an explicit dollar value, but this comes down to effort vs reward. Humans will switch focus while agents are working through their tasks, so the longer it takes for agents to respond, the longer it takes for humans to review and kick off the agent again. Its like a phantom traffic jam, the first car breaks without reason, compounds to the next, ending up bringing traffic 5km back to a complete standstill. They still arrive at their destination in the same condition, but delayed and having consumed more fuel. Why delay this process, when you know you’ll tackle it all in one go later. ↩︎
-
If you are in an enterprise organisation with CAB, ARB, RFC, TDA, etc, these still need to be respected, and just more AI-assisted hardening steps as a gateway to Performing. One can only hope that these institutions are augmenting these processes with AI too. ↩︎