Mission-as-Template : Declarative AI Agents in Production
Most agent frameworks treat an agent as a hardcoded prompt plus a tool list, instantiated per call. That model breaks the moment multiple users instantiate the same agent against different inputs, the moment a security team asks who has access to which capability, and the moment a non-technical user wants to launch an agent without writing a prompt. The CompanyManager plugin in the I-Machine platform solves the same problem differently : An agent is a typed mission template, not a string of text. This article describes the model and what it enables.
The unit of declaration : The mission template
A mission template is a versioned, server-side artefact that describes a class of agents. It declares :
- A capability schema (typed inputs the mission expects)
- The system prompt, with placeholder tokens of the form
{x}bound to schema fields - The set of MCP tools the mission is allowed to call
- Output and proposal contracts
A running agent is an instance of a template plus a set of per-run inputs that satisfy its schema. The instance never mutates the template ; The storage layer that holds templates is write-protected against agent runtime code, and template edits are an explicit, versioned operation distinct from agent invocation.
Server-side substitution
When a mission starts, the server resolves the template, takes the per-run inputs, validates them against the capability schema, and performs {x} substitution against the system prompt. The brain never sees the template pre-substitution and the user never sees the post-substitution prompt ; The composition happens server-side, under the same access control as every other tool call.
That separation has two practical effects. First, prompt injection through the inputs is structurally constrained ; A field declared as customer_id : string in the schema cannot smuggle a new instruction into the system prompt because its substitution site is fixed and its content is typed. Second, audit becomes trivial : The template version plus the inputs fully determine what the brain saw, so a recorded run is fully reproducible without storing the rendered prompt.
Live resolution of agent identity
A running Agent in the platform holds a templateId reference rather than a frozen copy of the template fields. At every call boundary the server resolves that reference through the TemplateService to get the current system prompt, tool set, and capability constraints. When a template is updated, every active and future instance picks up the change at its next iteration ; There is no fleet of stale agents running yesterday’s prompt.
The runtime implementation lands in the MissionRunner and the server-side agent tools that speak to the live combo of template plus inputs at every step. The client UI sees a single agent identity and a single capability surface ; The fact that the surface is recomputed per iteration is invisible to it.
What it buys an organisation
- Versioning and audit. Every mission is a version-controlled artefact. Every run carries the template version and the typed inputs. A compliance team can replay any session deterministically from those two facts.
- Non-technical instantiation. Users who shouldn’t be writing prompts don’t need to ; Mission instantiation is filling in a typed form, not crafting a system message.
- Prompt-injection resistance. The injection surface shrinks to the schema fields, which are typed, validated, and bound to fixed substitution sites.
- Capability boundaries. The tools an agent can call are declared on the template, enforced by the tool bridge, and re-resolved live ; They cannot be expanded by a clever prompt or a runtime patch.
- Configuration-drift containment. A mission that worked yesterday and broke today did so because the template version changed. The fix is a version bump on the template, not a hunt through prompt history.
The shape of a mission template
A template carries the fields described above, a unique identifier, and a version number ; The schema is typed in the server’s native model and serialised for transport when a client UI wants to edit it. Edits go through a save flow that preserves on-disk versions ; The client UI never overwrites an edited template in place, which avoids the class of bugs where a stale UI commits over a fresher version.
Where this fits
Mission-as-template sits on top of the agent loop described in Building a ReAct Agent on Top of MCP. It does not replace the loop ; It constrains what each instance of the loop is allowed to think and do. For the wider infrastructure context, see Self-Hosted MCP Infrastructure for Enterprise.