Agent Factory

also known as Agent Template Factory, Fleet Agent Provisioning

Manufacture agent instances from a versioned template that renders model, tools, and prompt atomically, with registry-backed identities, so a fleet stays consistent and one template change propagates instead of drifting per instance.

Context

A team runs not one agent but many instances of one or more agent types — the same support agent deployed per customer, per product line, or per region, each needing its own configuration. Every instance binds a model, a tool set, a system prompt, and policy settings. The team has to decide how to stand up and maintain dozens or hundreds of these instances so they stay consistent as the underlying definition changes.

Problem

Hand-configuring each instance, or copying a starter config and editing it, lets every instance drift: one keeps an old prompt, another points at a deprecated model, a third has a tool the others lack, and no one can say which version is running where. Rendering the pieces separately — prompt here, tool wiring there, model choice elsewhere — means a half-applied change can leave an instance internally inconsistent. When a fix has to reach the whole fleet, there is no single place to change it and no identity scheme to target instances, so updates are manual, partial, and unauditable.

Forces

Many instances of an agent type must stay consistent as the definition evolves.
Rendering model, tools, and prompt separately allows half-applied, internally inconsistent instances.
A fleet-wide fix needs one place to change and a way to target every affected instance.
Each instance still needs its own identity and per-instance configuration.
Without versioning and a registry, no one can say which definition is running where.

Example

A company deploys the same support agent to forty customers, each with its own knowledge base and branding. Early on each was copied and hand-edited; six months later three run an old prompt and one points at a retired model, and nobody can tell which. They move to an agent factory: one versioned template renders every instance atomically, each gets a registry id recording its template version, and a prompt fix re-renders the whole fleet from one change. Drift stops accumulating and an audit can list exactly what every customer is running.

Diagram

flowchart TD T[Versioned template<br/>model + tools + prompt + policy] --> F[Factory: atomic render] F --> I1[Instance A<br/>registry id + version] F --> I2[Instance B<br/>registry id + version] F --> I3[Instance C<br/>registry id + version] T -. template change .-> F I1 --> REG[(Registry: instance -> version)] I2 --> REG I3 --> REG

Solution

Therefore:

Define each agent type as a versioned template that names its model, tools, prompt, and policy as one unit. A factory renders an instance from the template in a single atomic pass — never piecemeal — and registers it under a stable id with its template version recorded. Instances are managed through a lifecycle (create, read, update, retire), and a change to the template re-renders or migrates every instance bound to it, so a fleet-wide fix propagates from one place. The registry answers which template version each running instance carries, making drift visible and the fleet auditable.

What this pattern forbids. An instance cannot be assembled piecemeal or edited in place out of band; it may only be rendered atomically from a versioned template and must carry a registry identity recording that version.

And the patterns that stand alongside it, or against it —

complementsAgent Persona Profile★— Treat agent identity as a structured profile object — persona, primary motivator, allowed actions, knowledge bindings — rather than a free-form role sentence in the system prompt.
complementsAgentic Golden Path★— Constrain an agent to the platform's curated golden path of living, machine-readable standards and check for drift as it works, so its output is compliant by construction rather than corrected later.