SEIF One agent system
Every surface of the Workstation (the Agent Workspace, the Team, Go live, on the desktop and on the web) works on the same agents, with the same models, the same capabilities, one queue of what needs a person and one way of publishing. Each concern has one engine module; the surfaces read and write it, never a copy.
| Concern | One place | Used by |
|---|---|---|
| Models | runtime/engine/models.mjs | Agent Workspace, Team, Go live, connection checks |
| The agent | its files: agents/<id>/AGENT.md, objectives/*.md, context.yaml | Agent Workspace, Team, Go live, Lab, World |
| Capabilities | runtime/engine/agent-capabilities.mjs (built-in) and Tool contracts (tools/*.tool.yaml) | Agent Workspace, Team, Go live |
| What needs a person | runtime/engine/approvals.mjs, decided through runtime/engine/needs-you.mjs | Team (Needs you), Agent Workspace (Needs you) |
| Publishing | agent releases (runtime/engine/releases.mjs); Go live serves the draft or a release | Agent Workspace, Go live |
tests/engine/surface-coherence.test.mjs fails when a model provider, a built-in capability or a kind of approval is added in the engine and a screen does not offer it. tests/engine/unified-agents.test.mjs, tests/Workstation.Tests/UnifiedAgentsUiTests.cs and the last test of web/team.test.mjs prove each concern end to end.
Models
models.mjs holds the catalog of providers, normalizes a choice, resolves its credential and builds one provider with the chat() port of @and2carvalho/seif-llm-core.
| Provider | Credential | Where |
|---|---|---|
| Claude (Anthropic API), with Claude's own web search and fetch | the key in this computer's vault (vault:model.anthropic), an environment variable, or the account key on the web | everywhere |
| OpenAI-compatible (OpenAI, OpenRouter, Groq, LM Studio…) | vault, environment variable or project secret | everywhere |
| Ollama | none | everywhere (public HTTPS on the web) |
| Installed CLI (Claude Code, Kiro CLI, Codex) | the client's own saved login | desktop only |
| Rehearsal | none: labelled answers without a model | everywhere |
The live agent and team loop (llm.mjs) and the Agent Workspace loop call the same provider objects. A project file (launch.yaml, team.yaml) names only a provider and a model; only this computer's configuration may name a credential variable or an executable.
In a project made of files, the Agent Workspace's development model is the project's brain (Data & go live): choosing it in either place changes both. Other environments keep their own connections in agent-bindings.json.
The agent
An agent is its files. The Agent Workspace opens projects made of files directly (desktop: from the World, from a team member, or from Home; web: the Agents tab), as well as legacy JSON projects.
| Agent Workspace field | Where it lives |
|---|---|
| Name, purpose | the consumer in AGENT.md |
| Instructions | the objective's file, e.g. agents/guru/objectives/work.md (rendered into the context once) |
| Model connection key, response contract, limits, scenarios | the workspace: block of AGENT.md |
| Built-in capabilities | workspace.<id>.capabilities in AGENT.md |
| Knowledge, Tool contracts it may use | its Context Profile in context.yaml |
Edits made in the Agent Workspace go to those files (runtime/engine/file-writer.mjs): new written knowledge becomes a note under knowledge/, a new capability tools/<id>.tool.yaml, a context check tests/<id>.ctx.md, a new agent agents/<id>/. Every change is validated by loading the project; if it would not load, every file returns to what it was. Removing records is done in the Lab.
A team member is an ordinary agent: Setup → Agent Workspace… opens it; it can be tried, tested and released there, and the Team runs the same definition. team.yaml keeps only what is about the team: who leads, titles, flows, routines, budget, watched projects. Context engineering of a project made of files is the Lab.
Capabilities
A capability is something an agent may do besides answering. One list per agent, two kinds:
| Built-in | What it does | Team | Go live | Agent Workspace |
|---|---|---|---|---|
| Shared documents | reads and writes team/ | ✓ | ✓ | |
| The web | Claude's own search and fetch; other brains read public pages already seen in the work | ✓ | ✓ | |
| Connected data | the project's read-only lookups | ✓ | ✓ | ✓ |
| Usage of live agents | what people ask the live agents | ✓ | ✓ | |
| Prepare messages to send | a person approves the exact text | ✓ | ✓ |
An agent that never chose has connected data, as a live agent always had; a team member written before this keeps its team.yaml abilities until the team is saved. Grant or revoke them in the Agent Workspace (Capabilities → Built in) or in the Team's Setup → May: both write the agent's file.
Tool contracts granted by the agent's profile and connected in the development environment are offered on every surface: a team member, the live agent and an Agent Workspace conversation can all call them. They run through one executor path (confirmExecutor and dispatchToExecutor in tool-runtime.mjs, shared with the context runtime's gateway): the exact contract is confirmed, arguments are validated, call limits apply, and a write waits for a person.
What needs a person
One queue per project, whichever surface asked:
| Kind | Asked by | Applied by |
|---|---|---|
| Message to send | a team member, or an agent in the Agent Workspace | delivered as the team's always are: WhatsApp from the connected number, email in your email app, or copied |
| Question, report, stuck work | a team member | the team's board |
| Action (a write of a Tool contract) | a team member or the live agent | dispatched once, with exactly the arguments shown, only if the contract has not changed since |
| Action asked in an Agent Workspace conversation | a draft preview or a published turn | the agent service's gateway, which recorded the exact call |
The Team's Needs you and the Agent Workspace's Needs you show the same list (desktop and web). Calls asked in an Agent Workspace conversation are decided in the Agent Workspace, where their gateway runs; the Team shows them with a link there.
Publishing
An agent is published by creating a tested release in the Agent Workspace. A release pins its instructions, knowledge and built-in capabilities. Go live serves one agent of a project made of files on the chat link, WhatsApp, the site widget and the API:
- the working draft: the agent's files as they are now;
- a release: exactly what was tested (
release: guru-v2inlaunch.yaml).
Choose it in Go live (Version) or in the Agent Workspace (Releases → Serve on Go live, Integrate → Go live). Every answer records which version answered. Agent releases of JSON projects keep their own environment routes and application API.
Boundaries
- Built-in capabilities and Go live belong to projects made of files; JSON projects keep Tool contracts and releases.
- Installed CLIs run only in the desktop app.
- A JSON project converted on the web still works, but conversion is no longer needed to use the Agent Workspace.