Engineers Go Forward to Build. Architects Go Forward to Decide.

Few Days back I shared a stage at AWS Cloud and AI Day in Kuala Lumpur with Clarence, a Senior Architect at AWS. The session was called "From Demo to Deployment: Solving Agentic AI's Toughest Challenges." Clarence took the first half: the technology that carries an agent across the gap. I took the second half: the part of the problem that doesn't change when the technology does. This post is what I shared in my half, written down. Everything in it was said on that stage; the method belongs to the team I'm part of, and the opinions are mine.

Every enterprise I talk to has the same story. A team builds an agent demo. It is impressive. Leadership gets excited. A budget appears. And then, somewhere between the demo and the day it was supposed to go live, the thing quietly dies. The industry has a number for this. S&P Global Market Intelligence surveyed over a thousand enterprises in 2025 and found that the average organisation scraps 46% of its AI proofs of concept before they reach production (Fortune, June 2025). Clarence opened our session with that number. I opened mine by disagreeing with it, or rather, with the way it is usually read.

The waste isn't the scrapping. It's scrapping late.

Almost half of proofs of concept get thrown away and the number is reported like you'd report a hospital's death rate. But throwing away a POC isn't a failure. That is the whole point of doing a POC. If every proof of concept graduated, we wouldn’t be proving anything we’d just be building slowly with extra ceremony.

That’s when the waste happens. Think of the cost of saying no as a curve that gets higher with every commitment you make to an idea. No free on a whiteboard. Once cloud resources are provisioned, there is a small cost. Once a budget is approved, it's a line item in someone's forecast. Once leadership believes in it, once there is a slide in the town hall, “no” costs reputations. After the provisioning, after the budget, after the belief, at the top of the curve is the industry’s 46 percent.

Some practices I'm involved with throw away more than 46% on purpose and do it at the bottom of the curve, before anybody has provisioned anything. This isn’t a cynical thing to say. That’s the only way I know to keep the appetite for ideas high, while keeping the bill low. Most organisations do not suffer from too few ideas or too little technology. The thing is, no one can see what an idea really looks like until they buy into it.

Documents are a lossy compression of imagination

Why don't they see it? It’s because of the chain we have to pass through to get from an idea to a working thing.

Somebody in the business comes up with something. Somebody else writes it down. A requirements document. A business case. Groomed backlog. Engineering builds what was written. Months later a demo comes out and no-one in the room recognises it.

The signal is lost every time a handoff is made in that chain. Picture a light bulb at the start of the chain, bright and specific. By the end it’s a boring generic bulb that technically fits the spec. That is not the fault of one person. That is what happens when you compress imagination into prose and then decompress it in a different head.

Agentic AI makes this much worse . The reason is easy to state but hard to accept : what a model actually does is not something that can be specified in a document . You can say “the agent summarises the contract and flags the risky clauses”, and that sentence is true of a thousand different behaviours, most of which the business will hate. You only know if it’s the right one when you see it running on your own messy data.

So the demo needs to come first. Not the paper. The demo .

The twist on a pattern

The AI industry has already converged on a response to this, and it’s a good one: the forward-deployed engineer. Place builders next to the customer, have them build the solution according to the customer, and ship a system. That's it. That’s how most of the serious AI labs are growing their enterprise business.

The architecture practice I’m part of isn't a software vendor, so the team twisted the pattern. We forward deploy architects, not engineers. And the twist is in what they are embedded with, and what they produce.

What an architect builds in the room is never a product. It’s a mirror. The business researches it and decides for itself if the idea is the one it was looking for. “Producing is a decision, not a system.”

The role has three duties:

• Expand. Most people in a business unit do not know what an agent can do until they have watched one do it. Part of the job is widening the imagination before narrowing it.
• Make it tangible. Show the idea of working, in the room, in hours. Roughly is fine. Running is mandatory.
• Translate. When something is deployed, someone has to carry the business need and its risks across to the teams who will operate it. That carrier is the architect.

We never tell the business if their idea is any good. We show the idea in a real-world setting and let the business decide. This is the line that the architects I work with use for this, and the one I said out loud on stage:

We are the business. We know the cost. We get things done.

The tooling changed the economies of the role. With a spec-driven prototyping tool and a managed model platform, an architect can do in an afternoon what used to take a squad and a sprint. Five years ago, 'make it tangible in hours' would have been a slogan. It's Tuesday now.

Two speeds, one governed path

Here's the whole method on one page and the session title is The Path.

There are ideas written on the whiteboard. Speed one takes hours. An immersion workshop where the business sees its ideas running and cuts most of them itself. One or two make it. Speed two takes weeks. A governed POC track. Where the survivors are built properly, under a harness, inside a cap. Each POC ends with one of the four exits. Of those exits, only one leads to deployment, and that is via handshake with the teams that will run it.

Everything is executed in a managed cloud sandbox. No lead time for provisioning, nothing on a personal machine, nothing on a laptop.

Speed one: show the business its idea, then let it decide

Speed one is not about construction. It’s about creating a “aha” moment.

It works this way. The business says what it wants. In plain English. A spec-driven tool takes that intent and turns it into a spec we read together on screen, and then turns the spec into a running prototype, live, while the coffee is still hot. A data-exploration tool that provides instant views and flows over the business’s own numbers, without a dashboard project in between. Ten ideas on the whiteboard, working prototypes by lunchtime.

The "aha" is rarely "yes, that’s it". The ‘aha’ is often: "Actually, that wasn’t the idea". That sentence is the cheapest "no" in the enterprise. "We don’t argue an idea down"; the prototype does it for us. Eight or nine out of ten ideas die the first day, killed by the people who had them.

Then we throw prototypes in the trash. No production provisioned Everything is kept. If you keep speed-one artefacts, they are the backlog and you have rebuilt the lossy chain with more steps.

Sidebar: the spec is the new BRD

The business requirements document was never a bad idea. It was a slow one – It's a spec written in minutes, in the words of the business itself, that does the same job the BRD was supposed to do, with the one property the BRD never had: you can see if it's right. What matters far less is what tool writes the spec than that the business reads it on screen before the prototype runs.

Speed two: safeguard, don't police

The one or two survivors go into speed two, and this is where governance applies. The posture matters more than the mechanics: governance here is a support beam, not a gate.

Two guardrails are set at intake, before anything is built:

• Capped scope. Every POC has a lease, a fixed time-box, and a success metric agreed before it starts.
• Capped spend. The budget is set at intake, not discovered at invoice.

Inside the lane, two instruments:

• An evaluation harness. We watch consistency, grounding, drift, and cost as the scale goes up. Not at the end; continuously.
• Behaviour on watch. The forward-deployed team stays inside the POC and the business sponsor stays in the room.

Representative data, never real users. Time-boxed, budget-capped, evaluated. The harness is not homemade; it is built on the same managed evaluation, observability, and guardrail primitives the agent would run on if it graduates. That last point matters more than it sounds, and I will come back to it.

Four exits. Three are successes.

Every POC reaches a switch, and we say the four positions out loud at intake, so nobody is surprised at the end.

• Iterate. The hypothesis moved. Run another bounded cycle. Success.
• Kill. The hypothesis was disproven, cheaply, and the learning is captured. Success. A kill with a documented reason is the 46% done right.
• Park. Right idea, wrong time. The data or dependency isn't ready. Success.
• Graduate. Validated under POC conditions, offered to the teams who will run it. The rare one, and the one with the most obligations attached.

If you only count graduations, you will get the behavior you reward teams who refuse to kill, who park nothing, who iterate forever. Saying out loud that three of the four exits are wins is the single cheapest cultural change in this whole method.

The handshake

POC-validated is not ready for production. Validated by a POC means a hypothesis, representative data, bounded scenarios and an evaluation harness. Production ready means real load, drift monitoring, incident handling and an operational owner. These are delivered by the receiving teams, under their own discipline, and not by the people that ran the POC.

What crosses the gap is a handclasp. When an agent graduates, the forward-deployed team does not disappear, and does not take over. It gives the receiving team a watch-list: where the data is thin, where the model hallucinated, what happens to cost at 10x the load.

And look at what’s holding the bridge up. The headings of that watch-list are the four pillars of Clarence:

The receiving team owns deployment. We own the honesty of the handshake.

Sidebar: map each pillar to a primitive, not a product

Every pillar above corresponds to a capability your platform should give you: an observability layer that emits traces, a managed knowledge store with grounding, an evaluation service, guardrails and identity propagation. Any mature cloud platform offers all four. The handshake survives the handover because each watch-list heading points at a capability the receiving team will actually operate, not at a slide. Which platform provides the capability is a procurement question. Whether the capability is wired in before graduation is an architecture question.

Where technology fits, and why the method is written in capabilities

Two speeds need two tooling speeds.

Governed sandbox, a tool that takes intent and creates a working prototype. The solution for putting views over real data in minutes. No lead time. No sensitive data on a personal machine. Tooling for speed. Speed two means the agent you evaluate is built on the primitives it will run on later. So the harness in week two is the monitoring in month six.

You’ll see that I’ve written this list, and this whole post, in terms of capabilities and not products. That is deliberate and not a hedge. We run this on AWS, which is why I was on their stage, and the technology I would point anyone at is Clarence's half of the session. I said too on that stage that we didn't pick the prototyping tool we use because of whose event we were at; it went through the same tech evaluation as everything else and won on merit, and it will be evaluated again, like everything else. A method must be able to survive that. If it is written in product names, the next evaluation would rewrite the method. Or written in terms of capabilities the next assessment just changes which box gets ticked under which heading.

That’s half the problem I wanted to talk about. Clarence showed us the tech that gets an agent across the chasm. He was on every pillar. The tech half is the half that you can buy. The organisational half is the half you have to build. It’s the half that’s still there after every platform decision you will ever make.

One thing to take home

Technology alone does not bridge the gap from demo to deployment. It is crossed by putting architects next to business, making imagination tangible in hours, killing cheaply, graduating deliberately, and shaking hands honestly with the people who run production.

From demo to deployment, technology gets an agent. Architects, forward deployed, decide which demo is worth the trip.

Let's Summarize

• Scrapping 46% of AI proofs of concept is not the waste; scrapping them late is. The cost of saying no climbs with every commitment.
• Documents are a lossy compression of imagination, and an agent's behaviour cannot be specified on paper. Show the demo first.
• Forward-deploy architects, not engineers: embedded with the business, making the idea visible, producing a decision rather than a system.
• Two speeds, one governed path: hours for the business to kill its own ideas, weeks of capped, evaluated POCs for the survivors.
• Four exits, three of them successes. Only graduation crosses to production, through an honest handshake built on the four pillars.
• Write the method in capabilities, not products, so it survives the next platform decision.

..and for reference

S&P Global Market Intelligence - Voice of the Enterprise: AI & Machine Learning, Use Cases 2025, as reported by Fortune, 11 June 2025
Clarence Anslem, Senior Architect at AWS - for the other half of the session, and for the four pillars

The views in this post are my own and do not represent my employer or AWS. The method described is the curated by a team of AI, Data and Architects specialists; I am one of the people in the room.

Cheers,
Mohammad Malekmakan

Disclaimer:

All opinions and content published in my blog and my social networks are solely my own, not those of my employer(s) and the communities I am contributing in.