Agent Factory

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.

Solution

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.

When to use

• Many instances of one or more agent types run, each with its own configuration.
• Instances must stay consistent as the underlying definition evolves.
• A fleet-wide change must reach every affected instance reliably.
• Auditing which definition version each instance runs matters.