Define an agent

To define an agent in Isolation you fill in four things: a name, an AI credential, a model and instructions. That is the whole roster entry. You never pick a harness; the harness follows the credential you chose. An agent is a definition, not a process. A running one is a view of type agent inside a session, which is where the definition becomes a real harness session with tools, a working directory and a conversation.

What an agent is made of

A few more fields exist for people who want them: an avatar (emoji and color), a tool profile (reader, developer or maintainer, plus explicit allow and require-approval lists), a working directory relative to /workspace, an idle timeout and a maximum turn length in seconds. Anything you do not set has a sensible default.

Which harness runs it?

The credential decides. This is the execution model, and it is the same on every server:

Every harness speaks ACP, so the agent view looks and behaves the same whichever one runs underneath: streaming replies, tool calls, diffs, permissions, slash commands and modes. The credential itself never enters the definition; the roster stores a reference to it, and the secret travels sealed to the server at launch. How keys and subscriptions are stored and metered is on AI providers.

Isla, the starter agent

Every membership begins with one agent, Isla. She is created at the moment you create an organization or accept an invite to one, and her instructions describe a careful senior engineer: read before you write, work in small verifiable steps and report what actually happened, ask before anything large or destructive, never print or commit secrets, keep answers short and concrete. Isla is an ordinary roster entry. Rename her, rewrite her instructions, move her to a different credential, or delete her and start from scratch.

She arrives without a credential, and an agent without one cannot think: her view opens, but the first message is refused until you assign her a personal AI credential on the Credentials page (an API key or a Claude or ChatGPT subscription) and pick her model. That is the one setup step between a new membership and a working agent; the options are in AI providers.

Where the roster lives

The roster is yours, per organization. It belongs to the member, not to the workspace and not to the team, and it exists inside one organization at a time: joining a second organization starts a fresh roster there, with its own Isla. Roles and membership are covered under organizations, roles and invites.

Every session you launch gets the whole roster. Nothing is attached to a workspace ahead of time; the session screen simply offers every agent you have, and you open an agent view for the ones you want to talk to. Each agent keeps its own memory and HOME per workspace, described on memory and conversations.

Adding and changing agents

The Agents page in the website is the full editor. The same definition is reachable as actions from every other door, so you can also do it from a chat app or an MCP client:

/roster                        who you have
/new-agent Reviewer            add an agent named Reviewer
/ask Reviewer look at src/     one turn with it, in the current session

The MCP tools are agents_list, agent_create, agent_update and agent_delete. agent_update changes only the fields you send and takes an optional revision number, so two people editing the same agent are told about the collision rather than silently overwriting each other. Deleting an agent does not touch sessions already running; new sessions no longer include it.

One more thing is minted with every agent and shown on the roster: its own Nostr public key (npub). That key is the agent's identity in a Buzz community, and it is why an agent can be added to a channel the way a person is. See Nostr and Buzz.