The forward deployed model: putting builders inside the business

The distance problem

A typical software project runs like this. A business team writes down what it needs. An analyst turns that into a specification. A development team, often in another office or another company, builds against the specification. Weeks later, the business team sees the result and discovers that half of what mattered was never written down.

With conventional software this is painful but survivable. With AI applications it is much worse, because the important details are exactly the ones nobody thinks to write down. The collections officer knows that borrowers in one district respond better to a call after 6 in the evening. The accounts executive knows that one supplier's invoices always show freight separately and should be matched against two purchase order lines. The ward nurse knows which parts of a discharge summary the patient's family actually reads. An agent built without this knowledge will be technically correct and practically useless.

The forward deployed model is a response to this distance. It puts the builders inside the business, working alongside the people whose work is changing, for the length of the build.

Where the idea comes from

The term comes from software companies that sold complex platforms to large organisations and found that the platform alone was not enough. Someone had to sit with the customer, understand the work and configure or extend the product until it fitted. These people were engineers, but their job was as much about understanding the business as about writing code.

AI has made the model more relevant. Modern AI platforms, including low code builders, can do a great deal out of the box. The gap between "the platform can do this" and "our team uses this every day" is mostly a gap in understanding the work. The technology is usually ready. Forward deployed people close that gap.

Two roles

The forward deployed engineer

The engineer builds. They configure flows and agents, write the integrations with Tally, the CRM or the hospital information system, prepare the data, set up access controls and build the review screens. What makes them forward deployed is that they do this inside the team. They sit with the accounts executives during month end. They watch how the support team handles a refund request on WhatsApp. They see the exceptions with their own eyes, as they happen.

A good forward deployed engineer is comfortable with ambiguity. The requirement on Monday is often wrong by Wednesday, because watching the work showed something nobody had mentioned. They need to be able to change direction without drama and explain technical limits in plain language.

The forward deployed strategist

The strategist owns the problem. They map the current process, find where an agent would actually save time, define how success will be measured, design where people stay in control and manage the change with the team. They talk to the head of collections about what the agent must never say to a borrower. They work out with the admissions head which enquiries can be answered automatically and which need a counsellor's call.

Many AI projects fail because nobody worked out how the team's day would change once the agent existed, even when the agent itself was built well. Who reviews the agent's drafts? What happens to the person who used to do the work by hand? How do you know, three months later, whether it is helping? These are strategy questions, and they need someone whose job is to answer them.

How an engagement runs

Most engagements follow three phases, with details that change for each organisation.

Weeks one and two: watch the work

The team spends time with the people who do the work today. They sit with the Rajkot distributor's accounts team as they match supplier invoices to purchase orders in Tally. They listen to collection calls. They read a hundred real discharge summaries. They note every exception, workaround and frustration. By the end, they can describe the process better than the written procedure does.

Weeks three to six: build something narrow and real

The engineer builds a first working version for one well defined part of the process, connected to at least one real system. The strategist designs the review step and agrees what the agent must never do. The team uses it on live work, with every output reviewed before it takes effect.

Weeks seven onwards: widen, measure, hand over

Once the narrow version works, the scope widens: more suppliers, more types of enquiry, another department. The strategist measures against the baseline recorded at the start. The engineer documents what was built and trains the team's own people to make day to day changes. The goal is to leave behind something the business can run and adjust without the forward deployed team present.

Why it tends to work

The main advantage is speed of learning. When the builder sees a wrong output and the person who knows why it is wrong is sitting two desks away, the fix takes an hour. In a conventional project it takes a ticket, a meeting and a sprint.

The second advantage is trust. Teams are understandably wary of AI systems that arrive from outside and change their work. When the people building the system have sat through their month end, they are more likely to build something the team will use, and the team is more likely to tell them honestly when it is not working.

The third is that the business ends up owning the result. Because the build happened in front of them, the team understands how the agent works, where its limits are and how to change it. That makes the difference between a project that survives after the consultants leave and one that slowly falls out of use.

Where it fits poorly

The model struggles in four situations.

It is expensive per person. Putting experienced engineers and strategists inside a team costs more per hour of work than a remote team building against a specification. It pays off when the work is ambiguous and the business knowledge matters. For a well specified integration with a documented API, a conventional delivery model is cheaper and perfectly adequate.

It needs access. The team has to see real data, sit in real meetings and talk to the people doing the work. Some organisations, especially in banking and healthcare, find this hard to arrange quickly. If access takes two months to approve, the model loses much of its advantage.

It needs a willing team. If the people whose work is changing see the project as a threat, having builders sit with them can make tension worse. The strategist has to address this directly and early, and leadership has to be clear about what the project is for.

It can create dependence. If the forward deployed team does everything and hands over nothing, the organisation is left with a system it cannot maintain. Handover has to be planned from the first week.

Buying it

At Code Colonies, forward deployed engineering is one of three engagement models, alongside output based work and the startup engine. In a forward deployed engagement, engineers and strategists work inside your team, usually building on the AksharAI platform where it fits and writing code where it does not. Where the work is well defined, such as a specific integration or a custom component, it can be bought on 2good terms instead: billed by the hour, with no advance and payment after you accept the work.

Training people for the role

Good forward deployed people are hard to find, because the role asks for an unusual mix. Engineers need to be comfortable in a room with the accounts team. Strategists need to understand enough about models, data and integration to know what is realistic. Neither skill is taught well in a classroom.

AksharAI runs the Forward Deployed Professional programme for this reason. It is 500 hours of training, taken over three months full time or six months part time, and it is fully remote. There are two tracks, Forward Deployed Engineer and Forward Deployed Strategist, matching the two roles. Most of the time goes into live project work with mentors, so participants learn by doing the job: watching a process, building something narrow, reviewing outputs with a real team and handing over. Those who complete it receive a certificate that names their track.

The programme suits graduates and early career professionals who want to work on applied AI in real businesses, and people already in technology or operations roles who want to move closer to the work AI is changing. It is demanding, and the project work is real.

What to ask before you start

If you are considering a forward deployed engagement, a few questions help decide whether it fits:

• Is the process ambiguous enough that business knowledge will shape the build, or is it already well specified?
• Can the team get access to real data and real people within a couple of weeks?
• Is there a named owner in the business who will make decisions quickly?
• Has leadership explained to the team what the project is for and what it is not for?
• Is there a plan for who maintains the system after the forward deployed team leaves?

If the answers are mostly yes, putting builders inside the business is likely to be the fastest route to something that works. If they are mostly no, fix those first, whatever delivery model you choose.

If you want to train for one of these roles, read about the Forward Deployed Professional programme.