Agents

An Agent combines instructions, documents, workflows and connected tools for a job. Use one for support, business analysis, a product area or a client account. Configure it in Fermium, then work with it through your preferred AI tool using Fermium MCP or through optional hosted chat.

Your AI tool calls list_agents to discover the Agents you may access, then load_agent with agent: "support" to load one. It can use several permitted Agents as needed. Loading context does not launch hosted chat or grant access to documents you could not already read.

For a data analyst Agent, add schema documentation and metric definitions as sources, write workflows for choosing and validating queries, and connect the approved data tools. Workflows guide the AI; the connected data service must enforce database permissions, read-only roles and query limits.

Agents were previously called Brains. Existing links, stored BRAIN.md files and API integrations remain compatible. The MCP naming guide explains the current tool names and retained response fields.

Start with: “Load the Delivery Agent, compare the client brief with our project notes, and prepare a list of missing requirements with links to the sources.” Your existing agent gathers the context and does the work. Saving a conclusion to Agent memory makes it available to that Agent's audience.

Documents live in roots and folders. An Agent's sources point at them, so edits stay current and existing document permissions still apply.

Try a customer proposal

New personal Agents include skills/customer-proposal.md and workflows/customer-proposal.md: writing rules, a repeatable brief → outline → build → review → publish process, and a complete HTML slideshow template. The template uses placeholders for customer details, scope, and prices.

For an existing personal or workspace Agent, open Files → Add proposal starter. This adds missing starter files and index links while preserving existing files. It requires a signed-in person with write access. Agents can propose changes to these protected files; a person reviews them as usual.

Try: “Load my personal Agent and follow its customer proposal workflow using this brief. Prepare the slideshow for review.” See the proposal example. You can adapt the skill and workflow to your own brand and process in the app.

Availability: connected MCP tools, optional hosted chat, private sessions, reviewed knowledge and public knowledge deployments are available in Fermium. Hosted work requires configured models and workspace funding. Ordinary Agent context and memory tools continue to work with the agent you already use. See Chat with an Agent and deploy it.

Files and connected knowledge

BRAIN.md and INDEX.md are created with the Agent and cannot be deleted. See the MCP reference for file naming and write parameters.

Every file is a markdown document underneath, so it has versions, a diff between any two, and restore. An agent also has a name, a slug (what AI tools pass as agent), an icon and a one-line description.

Who can open an agent

Workspace owners and admins create agents and manage them: name, description, access, deletion. They always have write access, and so does the person who created the agent. Everyone else is on the agent's Access tab, as a person, a group or the whole workspace, at one of two levels:

Adding an entry to the Access list, or changing its level, needs the Business plan or above and is refused with a 402 that names the plan. Removing an entry works on every plan. Below Business the tab shows the list with a note and a link to billing, and entries that already exist keep applying.

The number of workspace agents depends on the plan: 1 on Free, 5 on Team, any number on Business and above. Personal agents do not count. Creating one past the limit is refused with a 402 that names the plan and the limit. Nothing is removed when a plan changes.

A workspace agent with nobody listed can be read by every member of the workspace; owners, admins and its creator manage it. Adding the first entry narrows reading to the list. A personal agent is only ever its owner's. Deleting an agent removes its files, journal and proposals; the documents its sources point at are untouched.

The personal agent

Every member has one personal agent, called My agent, created the first time agents are listed for them. It is private memory shared by every agent that member connects: preferences, how they like things written, what they are working on. Nobody else in the workspace can open it, owners and admins included. It cannot be shared, included in another agent or deleted. Agents address it as agent: "personal", and it is the default when load_agent or agent_search is called without an agent.

Use the personal agent for facts about the person and a workspace agent for facts about a concern.

Sources only narrow

A source links something the agent may read through to:

In Library, Add as a source to an agent… on a document, a folder or a selection adds it to an agent you can write to.

Sources are pointers. Nothing is copied, so agents always see the current version. And sources never widen access: what a caller gets is the overlap of the agent's sources and what that caller could already open. A document you may not open never appears for you, in the source index, in search or anywhere else, whatever a source names. Two people loading the same agent can see different source documents. ~ means personal documents: the caller's own, plus colleagues' personal documents the caller may open.

Agent files cannot be sources. To share skills and workflows between agents, use includes.

Includes

An agent can include other agents, in order: a brand agent included by support and by sales. An agent that loads the agent gets the included agents' skills and workflows after the agent's own, each marked with the agent it came from, and search covers them. Memory, the journal and sources are not included. Included agents can include others, up to three levels; cycles are refused, and a personal agent cannot be included. An included agent the caller cannot read contributes nothing, and the load says how many were withheld.

Proposals and review

BRAIN.md, skills and workflows set the rules, so they are protected. When an agent writes one of them with the agent tools, including a brand new skill or workflow, the file does not change. The call files a proposal: the complete new text, a message saying what changes and why, and the version it was based on.

• Who proposes. Anyone who can read the agent, and any agent acting for them. In the app, a reader's edit to a protected file goes to Review; a person with write access chooses between Save directly and Propose change.
• Who decides. A person with write access, signed in to the app. Agents and API tokens cannot approve or reject these knowledge proposals.
• How. The Review tab lists proposals, with a count on the tab. Opening one shows the diff hunk by hunk with a checkbox per hunk. Approve everything, approve only the selected hunks, or reject, with an optional note for the proposer. Approved hunks are written to the file as a new version; the rest are dropped.
• Statuses. pending, approved, partial (some hunks accepted), rejected, and stale.
• Stale proposals. If intervening edits prevent a proposal from applying, it is marked stale and no change is saved. Read the latest file and submit a revised proposal. The review screen shows when the file changed since the proposal.
• Notifications. Filing a proposal notifies everyone with write access through the bell in the app's top bar; deciding one notifies the proposer with the outcome and the note. Each notification links to the proposal.

Deleting a protected file is also a person's job, in the app. Memory, the index and the journal are free write: people and agents with write access save at once, every version is kept, and History on a file compares and restores.

A write that starts from an old version does not overwrite newer work. The tools take base_version; when the file has moved on, the write is refused with a conflict and a diff.

Short-term and long-term memory

Short-term memory is the journal. agent_remember appends a note: one durable fact, decision, preference or correction, written so it makes sense without the conversation, at most 4,000 characters, with an optional topic label such as acme or style. Every load returns the 20 most recent notes that have not been consolidated. The journal also records what agents did: loads, reads, searches, writes with a small diff and the message, proposals and decisions, each with who and when. agent_log reads it back, so a new session picks up where the last one stopped. A person browsing files in the app is not recorded; people can add notes from the Activity tab.

Long-term memory is the files. Knowledge that should last goes into memory/<topic>.md, one topic per file, listed in INDEX.md. The files and their version history are what stays.

Agent notes and memory have the Agent's audience. Use your personal Agent for private preferences; do not put a private client conversation into a workspace Agent unless it is appropriate to share with that audience. The local implementation's private resumable hosted chat sessions are separate from the existing journal. Store credentials in Secrets, not in instructions, notes or memory files.

Consolidation and the journal budget

Notes are cheap to write and expensive to reload forever, so the journal has a budget: 40,000 characters of notes that have not been consolidated, by default. The Activity tab shows the meter. When the budget is passed, the next load says consolidation.needed with a hint, and the agent is asked to:

1. read the old notes (agent_log with kinds: ["note"] and unconsolidated: true);
2. fold what is durable into memory files with agent_write, and update INDEX.md;
3. call agent_consolidate_mark with the note ids and the memory file that now holds them.

Marked notes stop counting against the budget and drop out of the recent notes. Nothing is deleted: they stay in the journal, linked to the file. The agent's own model does the reading and writing; Fermium stores the result. The budget can be changed per agent through the REST API, between 1,000 and 2,000,000 characters.

The agent in the app

Agents in the rail lists your private Agent and the workspace Agents you can access. Cards show the effective audience, file count and last update. An Agent opens to Overview, with its purpose, knowledge, connected tools, review work and recent conversations.

• Use with MCP in the header connects your existing AI and lets you inspect the context it receives. Hosted chat and credits are optional.
• Knowledge groups Agent files, linked sources and included Agents. The file tree appears here; files retain editing, history and protected-change review.
• Chat offers private resumable work, sources and outputs, and explicit sharing.
• Tools attaches compatible remote MCP servers, verifies discovery, and stages policy changes for an explicit save.
• Publish prepares a separate public knowledge snapshot: save privately, test, review and publish.
• Activity shows recent events and expandable month/day history in UTC. Counts are factual activity totals, not generated claims of completed tasks.
• Review collects knowledge proposals and Agent tool requests. Workspace Audit remains the cross-Agent approval and event view.
• Settings contains access, details, export and deletion.

An empty workspace Agent access list means all workspace members can read and use its connected tools under policy. Adding the first selected-person/group entry narrows that audience; removing the final entry restores workspace-wide access. The interface warns before either transition. Conversations have their own access lists.

The tools, for any harness

The tools are plain MCP tools, so any client that speaks MCP can use an agent. Parameters and payloads are in the MCP reference.

load_agent takes a character budget, 60,000 by default. It returns a starting context and identifies any omitted material in truncated. Read the files relevant to the task with agent_read, or use get_file for connected source documents. The MCP reference covers the response fields.

Several agents in one session is normal: the personal agent for how you like things, support for the policy, brand through an include.

Prompts that work:

• "Load the support agent, then answer: what is our refund window?" list_agents, load_agent, agent_search for "refund", then get_file on the hit.
• "Remember that Acme renews in March and Dana is the contact." agent_remember on the agent for that customer, topic acme.
• "Remember that I want charts without gridlines." agent_remember on personal.
• "What did we change in the support agent yesterday?" agent_log with since and kinds: ["write", "decide"].
• "Write up what we learned about the billing migration." agent_read on memory/billing-migration.md if it exists, agent_write with base_version, then an INDEX.md update.
• "The tone rule in the support instructions is wrong, fix it." propose_change on BRAIN.md; the agent tells you it is waiting in Review.
• "Turn the weekly digest steps into a workflow for this agent." propose_change on workflows/weekly-digest.md.
• "Let the support agent read the Support folder in General." add_agent_source with kind folder and target general:Support.
• "The journal is over budget, tidy it." The consolidation steps above.
• "Create an agent for the Q3 launch." create_agent, then sources, memory files and a proposal for the real instructions.

Harnesses without MCP

Export in the app, agent_export, or GET /api/brain-roots/<slug>/export?format=md returns the whole agent as one markdown file: the instructions, the index, the skills and workflows (included agents' files marked with their origin) and the memory files. Paste it into a system prompt or save it as a project file. It is a snapshot: edits to it do not flow back, and the journal and the source documents are not part of it.

Connected MCP tools

Attach tools for the work an Agent supports: project management, support, reporting or another compatible remote MCP service. No vendor-specific preset is required.

1. Open the Agent's Tools tab as its owner or a workspace admin, or ask an authorized agent to configure the connection through MCP.
2. Paste the provider's Claude or Codex MCP add command, JSON/TOML configuration, or remote endpoint. Choose Review connection and check the detected server. Set up manually is available for other instructions.
3. Choose Connect and discover tools. Sign in with the provider if prompted, or enter its token securely in Fermium. If verification fails, retry without adding a duplicate connection. Choose policies and Research eligibility, review the displayed changes, then Save tool policies.
4. Check the Agent's access list in Settings: its readers can request these tools through the linked account. Sharing tool access never exposes the stored credential.
5. Use Run tool for a real scoped request and inspect its outcome in Audit.

Fermium supports remote Streamable HTTP and SSE with OAuth sign-in, bearer/API tokens, custom credential headers or no credential. Commands are read as configuration, never executed. Instructions using mcp-remote can be translated to the remote endpoint. Servers that require a local process or private-network access need a separately supported runtime; ask the provider for a remote endpoint.

Most OAuth providers register Fermium automatically. When a provider requires a registered client, expand Advanced sign-in settings for its client ID and Fermium's callback URL. A client registered for Claude's local callback may need a different registration for Fermium. Environment-variable references in pasted instructions prompt you to enter the credential; Fermium does not read your machine.

Fermium refreshes OAuth tokens when supported. If access expires or is revoked, the connection shows Reconnect required. Connection and Agent owners who can manage the Agent, plus workspace owners/admins, receive an in-app alert and an email when email delivery is configured. Alerts link back to Sign in / reconnect; manual tokens can be replaced through Replace credentials. Optional token expiry dates support proactive alerts. Unknown expiry is detected when the provider rejects a request. Repeated failures in the same incident do not produce duplicate alerts.

Your agent loads the Agent, discovers attached tools with list_agent_connections, then submits the exact action and intended use through request_agent_tool_call. Policy may allow it, allow it with a review flag, require human approval, or deny it. Admins and Auditors review requests; policy can require a different approver. See connected-tool parameters and approval handling. Agents can use prepare_agent_connection_from_setup, configure_agent_connection and discover_agent_connection_tools to configure metadata and discover schemas. A person signs in or enters required credentials through the returned secure setup_url; the agent never receives them. Tool-policy changes remain human controls. See the setup contract.

Example: “Use the Delivery Agent to compare the client brief with the connected project, explain what's missing, and draft issues. Create them after the required approval.” Your connected agent can carry out the steps individually or delegate them through the optional hosted Agent runtime.

One access rule

Every bulk read applies the same check as opening a single document: the source index, agent_search, the file tree, folder bundles, the change feed, ranked search, published sites, and file history and blame. A document you may not open is left out entirely, with no title, file list or snippet. Being a source of an agent never widens access to a document.