Two ways an engagement can run
E31 Consulting works in two forms: forward-deployed engineers who join the team on site, or an in-house project scoped to an outcome and handed back running on the customer's appliance.
· 4 min read
IN SHORT
An E31 Consulting engagement runs in one of two forms. Forward-deployed engineers join the team that owns the outcome, on site and inside the customer's network segment, and finish when that team can publish the next version alone. An in-house project takes a described outcome, builds it as a scoped piece of work, and hands it back running on the customer's own Czar.
Every engagement at E31 Consulting ends in the same place: a use case running on the customer's own appliance, published as a version their people can point to and change. The way there takes one of two forms, and the choice between them is the first real decision a customer makes with the practice.
The first form is forward-deployed. The second is an in-house project. They share the stack, the kind of engineer, and the handoff. They differ in where the engineers sit, how the work is learned, and what counts as the end.
Forward-deployed: joining the team that owns the outcome
In a forward-deployed engagement, E31-certified engineers join the team that is responsible for the result. They work on site, inside the customer's network segment, with the people who will run the use case once it exists.
The reason for being there is the packet. Every desk has one: what arrives, what a good result looks like, which step a person still has to take, and which system the result has to land in. None of that is reliably written down anywhere. It lives in how the desk actually works, and the only way to learn it is to sit with the desk.
So the engineers sit with it. They watch the work, ask about the exceptions, and build the first version with the operators looking on. When something is wrong, the person who knows it is wrong is in the room. When a bound needs to be set, the role that should approve is at the next desk.
A forward-deployed engagement is finished when those people can publish the next version themselves. Not when a demo works, and not when the engineers are satisfied. When the site team can open Agency Studio, change what needs changing, send it through the approval the version names, and publish, the engineers leave.
In-house project: a described outcome, handed back running
An in-house project starts differently. The customer describes what should be true when the work is done. A desk that drafts and waits for a person to approve. A corpus of the site's documents that people can question. A product that customers run under the customer's own name.
The same kind of engineer takes that description and turns it into a scope: the material the use case may read, the calls it may make, the role that approves, and the systems of record it has to reach. Then they build it on the customer's appliance and hand it back running.
What comes back is not a prototype. It is a published version with the operating picture inside it, the notes the operators need to change it, and a record of how it behaved during build. The customer's team receives a thing that works and the means to keep it working.
A project suits work that is already understood well enough to describe. If the customer can say what arrives and where it should land, and can name who approves, the project has what it needs.
What both forms share
Both forms build on the same three layers. Czar is the appliance in the customer's rack, or several Czars as a Czar Grid. Substrate is the platform on it: inference, retrieval over the site's documents, memory, adaptation, evaluation, integrity verification, and declared routes to on-premise systems. Agency is the agent layer: agents composed in Agency Studio, published as versions, governed by bounds, approved by named roles, and recorded in a run record.
Both forms respect the posture the customer already chose. Air-gapped work is built air-gapped. Connected work uses the systems the customer already secures. A mixed estate stays a mixed estate.
Both leave the customer holding everything: versions, adapters, corpora, records, documentation. Nothing leaves the building, and the engineers leave no path out behind them.
And both end with a team that can change what was built. The forward-deployed engagement gets there by building alongside that team. The project gets there by handing back the version with the notes and the picture that make the next change possible.
Picking a starting point
The practical question is how well the work is already understood. If the packet is clear and the people who own it can describe it in a sitting, a project can carry it. If the work is still mostly in the heads of the people doing it, forward-deployed is the form that learns it.
Many customers start with one form for the first use case and use the other for the second. The engagements page at /engagements describes both in more detail, and choosing between forward-deployed and a project walks through the decision itself.
Questions this raises
- Can an engagement switch from one form to the other partway through?
- Yes, when the scope is renamed to match. A project that uncovers a desk nobody had described often becomes a forward-deployed engagement for that desk. A forward-deployed team that has finished the first version sometimes hands a well-understood second version to a project.
- Do both forms require the engineers to be on site?
- Forward-deployed work is on site by definition, inside the customer's segment. A project can be built on site or against a scoped environment the customer provides, as long as the result runs on the customer's appliance in the customer's posture.
- Is one form cheaper than the other?
- Engagements are scoped and priced per engagement, so there is no standing answer. The honest comparison is which form reaches a running, maintainable version for the outcome you named, and that depends on how well the work is already understood.
KEEP READING