Agents and instructions

The four parts of an agent

An employee creates an agent by giving it a name and a level, and by connecting capabilities to it. The agent is born with its instruction already written, filled in from a template the administrator maintains. Name, level, instruction, connected capabilities — that is the whole of what an agent is.

There is one persona in the product: the employee. What an employee may do is decided by their role, not by a separate kind of account. An author is an employee who creates agents, and usually the person who then uses them. An administrator is an employee whose role also covers the catalogue, the instruction template, organisations and members, and decisions on irreversible actions. Administrators work in the same interface as everyone else; scripts are an additional route, not the only one.

The instruction is a file

The instruction is a file that sets the agent’s behaviour, close in spirit to an AGENTS.md. It is not a set of form fields. A file is read whole rather than in fragments, carries over to another agent intact, and gives a person and a skill one place to write.

Where the first version comes from

The administrator maintains an instruction template. Every new agent’s instruction is filled in from that template at creation, so an agent has stated behaviour before its author has written a line.

Two ways to change it

An author can talk the instruction into shape: discuss with the agent how it should behave, then ask a skill to save what was agreed. The change is visible to the author, and the next conversation runs under it. An author can also open the file in the interface and edit it directly, with no conversation involved. Both paths are first-class, and both write to the same file.

Version history records the source

The instruction has version history and rollback. Each entry shows what made the change: a person editing directly, or the saving skill writing up a conversation. Because both write to the same file, history that did not distinguish the two would make rollback blind.

Two levels of agent

An agent has one of two levels, set when it is created. The lower level answers and reads. The upper level does that and may also act irreversibly. The boundary between them is the right to take an action that cannot be undone. Before an irreversible action happens, it goes to a person for a decision.

Level is a property of an agent and of nothing else. It does not describe a subscription: what an installation carries is an edition, and an edition is not a level.

Capabilities and the catalogue

The catalogue is what the administrator has entered and allowed to roles: MCP servers, integrations and skills. It is the boundary of what an author can connect without going outside the installation. An author is offered only the capabilities allowed to their role.

Two rules hold regardless of an author’s rights:

• An author never registers an MCP server. Only an administrator does, and no set of rights changes that.
• A refusal names its reason. Connecting a capability the agent’s level does not permit, or installing a skill that does not exist, fails with the cause stated and the agent unchanged.

Skills from outside the catalogue

Skills differ from MCP servers in one respect: an author holding the right can ask for one in conversation, and it is installed from an external source. Any skill installable by npx skills add <name> can be installed this way. An author without that right gets no installation and a stated reason.

Who can see an agent

A new agent is visible to its author alone. Opening it to an org group is a separate action by the author, not a default. Opening it does not change the agent’s capabilities: a skill the author installed from outside keeps working, and now works for the whole group. This is a consequence of the rules above, not an exception: external code brought in by one employee then runs for everyone the agent is shared with.