In the podcast that gave this series its spine, Vasuman Moza proposes a 30-day plan for becoming a forward deployed engineer: build an agent, harden it, make it measurable, and learn to defend its value. As a portfolio exercise it is a good plan. It cannot compress years of engineering, domain and client judgement into a month, and nobody should hire on the assumption that it does.
A more honest promise:
In 30 days, a capable practitioner can produce evidence of forward deployed thinking. In 90 days, a team can establish a repeatable pilot method. Mastery develops through repeated production work.
This final part covers both: what an individual can build in a month, and what an organisation can establish in a quarter.
Sandveld Foods and Ironbark Digital are fictional, and their systems and figures are illustrative. Two things are happening at once. A junior engineer at Ironbark, two years out of university and keen to move into a pod, is doing the 30-day build as a portfolio project. And Sandveld, with its invoice-exceptions work now operating, is starting its second workflow: claims against retailers for short deliveries, where a retailer's distribution centre records fewer cases than Sandveld shipped.
The individual 30-day build
Choose one real but non-sensitive workflow: supplier onboarding, customer-query triage, sales research or document quality review. Ironbark's junior engineer chose supplier onboarding, using synthetic supplier packs modelled on the shape of real ones, with no actual supplier data.
Week 1: complete a real loop. Define the user and the outcome. Map the workflow and at least ten exceptions. Build a small agent or AI-assisted workflow, connect one or two controlled tools, use structured outputs, and record a complete trace and its cost. Checkpoint: the system completes a bounded task and shows what it did.
Week 2: make it recover. Define input and output schemas. Add authentication and permission boundaries. Test missing, malformed and conflicting data. Add timeouts, retries and idempotency where they belong, and a route to a person. Document failure and fallback behaviour. Checkpoint: the workflow fails visibly and safely.
Week 3: make it measurable. Build a small golden evaluation set and deterministic checks. Compare model options on the actual task. Measure quality, latency and cost. Record human corrections. Estimate the business baseline and a value range. Checkpoint: the builder can explain performance and limitations with evidence.
Week 4: defend the design. Produce current-state and future-state views. Explain where deterministic software, AI and people belong. Present the security, data and operational controls. Demonstrate failure cases, not only successes. Explain the commercial value and its assumptions, then ask practitioners and leaders to challenge it. Checkpoint: the portfolio holds working software, evaluation evidence, architecture and a business case.
The junior engineer's most useful week was the second. The onboarding flow handled a missing tax clearance document perfectly in week one, and in week two turned out to accept a bank confirmation letter for a different company name without complaint. Finding that, writing the test, and adding the stop-and-escalate path did more for the portfolio than any feature. It is the same rule Sandveld applies to supplier bank-detail changes, and the engineer's pod lead noticed.
The organisational 90-day pilot
The dates do not matter much. The sequence does.
Days 1 to 30: discover and decide.
- Appoint business, technical and service owners.
- Select one bounded workflow with accessible users and evidence.
- Map the current process and its exceptions.
- Establish baseline quality, time, cost and risk.
- Define the future-state responsibility model.
- Confirm architecture, data, security and regional constraints.
- Agree evaluation, value and stop criteria.
Days 31 to 60: build and harden.
- Implement the smallest end-to-end slice.
- Integrate with representative systems and data.
- Instrument traces, cost and evaluation.
- Add human review and policy controls.
- Test failures and rollback.
- Train the initial user and support cohort.
Days 61 to 90: prove and transfer.
- Run in shadow mode and compare with the current process.
- Release a bounded canary where the evidence permits.
- Measure adoption, correction, cost and outcome.
- Resolve ownership and support gaps.
- Package reusable connectors, templates and tests.
- Decide to scale, revise or stop.
Sandveld's claims pilot follows this sequence, but faster in places, because a good deal already exists: the discovery method, the evidence layer, the workbench pattern and the read integration with the ERP. The discovery still had to happen. Claims depend on retailer portals and proof-of-delivery documents that the invoice work never touched, and the first week of shadowing found that two of Sandveld's largest retail customers dispute claims in completely different ways.
The maturity model
| Level | Description | Evidence |
|---|---|---|
| 1. Demonstrate | Isolated prototypes show technical possibility | Demo and technical notes |
| 2. Discover | Real workflows and exceptions are mapped | Operating map and baseline |
| 3. Control | Evaluation, identity, cost and human gates exist | Test pack and control evidence |
| 4. Operate | Bounded production has owners, service objectives and incident response | Operational records and outcomes |
| 5. Scale | Reusable platform assets support several deployments | Shared components and portfolio measures |
Do not skip a level by renaming a prototype "production". Sandveld's first AI invoice product was presented as level 4 and was, on the evidence, level 1. Its invoice-exceptions work today is genuinely at level 4. The claims workflow starts at level 2, not level 1, because the organisation already knows how to discover.
A readiness assessment
Score each dimension from 0 to 3: 0 absent, 1 informal, 2 defined, 3 evidenced and repeatable.
| Dimension | Assessment question |
|---|---|
| Sponsorship | Is a business owner accountable for the outcome? |
| Access | Can the team observe practitioners and representative cases? |
| Engineering | Can the team build, integrate, test and operate production software? |
| Architecture | Are system boundaries, data and non-functional requirements explicit? |
| Evaluation | Are representative tests and release thresholds defined? |
| Governance | Are identity, authority, privacy and human decisions controlled? |
| Operations | Are support, incidents, recovery and change owned? |
| Economics | Can full cost and realised value be measured? |
| Productisation | Is there a path from local learning to reusable capability? |
| Handover | Can the organisation operate the service after the embedded phase? |
Low scores do not automatically block a pilot. They decide where authority must be limited and which capabilities to build first.
Sandveld scored the claims pilot before starting. Engineering, evaluation and operations came out at 3, because the invoice work had proved them. Access scored 1: retailer distribution centres are outside Sandveld's control, and their staff cannot be shadowed. Economics scored 2. So the pilot began with the agent at the Assist level only, drafting claim packs for a person to submit, and with a discovery task to get evidence from the retailers' side through the account managers who deal with them.
The architecture views an engagement needs
Use the smallest set of views that answers the decisions in front of you.
| View | Audience | Purpose |
|---|---|---|
| Business context and value | Executives and the sponsor | Why the work matters and how value will be measured |
| Current operating flow | Practitioners and analysts | How work, decisions and exceptions happen today |
| Future responsibility flow | Business, risk and product | What people, rules and AI will each do |
| Solution overview | A mixed stakeholder group | Major capabilities and system boundaries |
| Production architecture | Engineering and operations | Deployable components and integrations |
| Data and identity flow | Security, privacy and architecture | Data movement, classification, identity and authority |
| Evaluation and evidence | Quality, risk and engineering | How behaviour is tested, traced and released |
| Transition architecture | Programme and architecture | How the organisation moves safely from current to target state |
| Operating model | Executives and operations | Ownership, support, service levels, incidents and improvement |
Nine views is a ceiling, not a target. Sandveld's sprint used four: business context and value, current operating flow, future responsibility flow, and transition architecture. The rest arrived when there was something to decide with them.
Red flags
Any one of these is worth stopping to discuss. Several together mean the engagement is not yet forward deployed work, whatever it is called.
- The forward deployed team has no access to practitioners.
- The client wants implementation before discovery.
- No business owner is named.
- The solution depends on replacing core systems with no transition plan.
- "Human in the loop" has no defined reviewer capacity or authority.
- Evaluation is a handful of hand-picked prompts.
- Costs leave out integration, review, support and change.
- Production ownership is deferred until go-live.
- Every client receives unique code, with no path back to the product.
- The role is measured on prototypes rather than outcomes.
- Compensation or value claims are repeated without evidence.
What good looks like after 90 days
The outcome is not "we built an agent". After 90 days, the organisation should have:
- one verified operating map;
- one bounded production candidate;
- a reusable discovery method;
- an evaluation dataset and a release process;
- a standard architecture and evidence pattern;
- named owners and a support model;
- a measured value result, or a defensible decision to stop;
- a backlog of reusable platform improvements.
Stopping can be a successful outcome. If the evidence shows weak value, unacceptable risk or unavailable data before more money is spent, the 90 days did their job.
The short version
Thirty days builds evidence, not mastery. A month-long build is a portfolio, not a qualification.
Ninety days builds a method. Discover and decide, build and harden, prove and transfer.
Score readiness first. Low scores limit authority; they do not have to block the pilot.
Climb the staircase honestly. Renaming a prototype does not skip a level.
Stopping is a valid result. A defensible "no" is cheaper than an expensive wrong build.
That completes the series. It began with Greg Isenberg's conversation with Vasuman Moza, discussed in Part 1, whose three-stage spine holds up well: understand the business, build evaluations, deploy and support adoption. The parts in between added what a production organisation needs around that spine: discovery that observes real work, deliberate decisions about where intelligence lives, evidence before autonomy, integration with the estate you have, honest commercial stages, a team rather than a hero, and a method that can be repeated. Whatever the title on the business card, that is the capability worth building.
Start again from Part 1, or see every part on the series page. For the evidence layer that forward deployed work depends on, see The Agent Evidence Layer, and for what happens after go-live, production begins after deployment.
How CloudNala can help
We help organisations start forward deployed AI properly: scoring readiness before a pilot, running the 90-day sequence on one bounded workflow with clear stop criteria, producing the architecture views each decision needs, and leaving behind a discovery method, an evaluation set and an evidence pattern the next workflow can reuse. For teams building their own capability, we pair with your architects and engineers so the method stays with you when we leave.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book an AI Opportunity Sprint or write to us at consult@cloudnala.co.za