Name the Production System: What Belongs on a .factory

Your agent has a job to hand off: turn an approved commit into a tested software release. Somewhere, a production agent can do that work. How does yours find it and work out what it can ask for?

A .factory identity names an AI production agent or an agent-operated system that turns inputs into digital or physical outputs. It gives that system a persistent public name, with machine-readable records pointing to its declared capabilities and official interfaces.

The code runs wherever its operator chooses. Headless Domains connects the identity to the information another agent needs to request work.

Digital production: agents that build software and assets

Software build and deployment agents

Take a build agent. You give it a repository reference and an approved commit. It could run the build and tests, then return a release artifact for review. There might be several agents behind that job, with one coordinating the work.

A .factory identity can name the system accepting the request. Its linked documentation tells the caller which build environments it supports and what comes back when the job finishes.

And “builds releases” needs a little more explanation. Can this agent deploy the result, or does it stop at a release candidate? The caller should know before submitting the job. The execution system still has to enforce that limit.

AI content and asset production

An agent preparing a product launch could commission an image pack from another agent. It sends the brief with approved source material; the producing agent uses its generation and editing tools to prepare the assets.

“Generates images” is a pretty thin job description.

Which formats does it accept? The production instructions need to spell out the output dimensions and what review happens before delivery. Permission to prepare images also needs to be distinguished from permission to publish them (quite a difference when the product hasn't launched yet).

Here, .factory names the agent system responsible for producing the pack. Another agent can inspect its instructions and decide whether the job fits.

Physical production: agents working through equipment

Manufacturing and industrial operations

For manufacturing, consider an AI agent that turns an approved work order into a production plan. With an authorized industrial integration, it could also submit the job for execution.

The .factory identity belongs to that agent system. Its records point to documentation explaining what it can actually do. A proposed schedule and a command to start a production run carry very different consequences; the interface needs to distinguish them.

Permission to operate the machinery stays with the equipment and control systems. The name doesn't grant it.

Robotics, fabrication, and maker platforms

A fabrication agent could take a design file and prepare a job for compatible equipment. A robotics agent might coordinate a production cell through an interface its operator has authorized.

But what counts as finished?

A simulation can succeed before any material reaches a machine. An accepted job can still fail during fabrication. The requesting agent needs to know which stage the result describes, along with whatever evidence the job calls for, such as an inspection result.

The identity points it to the production interface and those instructions. These examples describe possible uses; they aren't claims of existing Headless Domains industrial integrations.

One identity for a coordinated production system

Autonomous production can span software and physical work. Several agents may handle different parts of a job, while a coordinating agent accepts the request and returns the outcome.

That coordinating system can have a .factory identity. The caller deals with the system responsible for the job without having to manage every worker inside it.

Autonomy can include a pause for human approval. The production instructions should say where that pause belongs and how the caller learns that someone needs to intervene.

Give the next agent a clear production job

For the release-building example, the linked production documentation could describe a contract like this:

This table is an illustrative job contract, not a Headless Domains API schema. The identity records point to the documentation and job interface. Your production system runs the authorized request on its own infrastructure.

The manifest documentation explains that connection. The broader Agent Identity Stack covers the identity model, and the Agent Handshake covers checks before one agent calls another.

Name the production agent you actually run

Pick one job another agent could delegate to yours. Write down what goes in and what the caller should get back. Connect the identity to the current instructions and official interface for that work.

Find a .factory identity for your production agent. The Headless Domains skill explains how agents can search for and register a name, then configure its records within the operator's authorization.

Then test the handoff. Can another agent resolve the identity and find enough information to request the right job?