The identity-first principle
A message belongs to an identified participant inside one agent’s perspective. Two people in a thread remain two actors when their messages enter a model’s context. Linking someone’s Slack and Telegram accounts requires explicit verification; a matching display name is not enough. An agent also needs an attributable external identity. Give each agent the accounts it should act through, and review the connector’s setup requirements. See Identity linking and Agent provisioning.The perspective principle
Each agent has its own view of actors, conversations, memory, and credentials. The control plane can host several agents without sharing their conversational knowledge. An agent does not learn that another participant is hosted in the same installation simply because the operator knows it. Isolation between agents is only one boundary. Within an agent’s perspective, information learned privately still needs audience checks before it can be used in a group reply. See Perspectives and Memory privacy.The conversation-graph principle
Conversation is durable structure: messages have authors, audiences, reply relationships, and an owning perspective. A model prompt is a bounded selection from that structure. It is not the canonical conversation store. This makes it possible to inspect history, retrieve relevant evidence, and explain a response without treating the last prompt as the whole truth. See Data model and Context resolution.The participation principle
An agent can observe a shared conversation without answering every message. Formation uses conversation shape, addressing, and engagement decisions to determine when it should participate. Silence should be inspectable just as a reply is. See Addressing and engagement.The explicit-state and blank-slate principle
A new Formation installation starts with no agents. The first agent and every later agent are provisioned through the same dashboard and API. Agent settings, connections, models, memory, and grants are durable state. Environment variables configure the process boundary, such as database access, public URL, and the master encryption key. See Installation and Versioned state.The cloud-first principle
The control-plane host does not implicitly become the agent’s workstation. Workspace and browser capabilities require configured providers and permissions. A tool’s credentials come from its declared connection or scoped secret use. Cloud-first describes a capability boundary; it does not require every provider to be a public SaaS service. See Tools and capabilities and Sandboxed execution.The adapter principle
Connectors translate platform messages. Model providers translate model requests and responses. Execution providers supply workspaces. Each exposes a contract and limitations without becoming the owner of the whole runtime. The supported adapters are listed in their guides. An architectural interface or provider name in a design document is not evidence that an integration is ready to configure. See Architecture and Model connectors.The work-topology principle
Work that outlives a turn needs durable state. Formation currently provides bounded runs, checkpoints, continuation, schedules, and commitments. These represent work and recovery at different levels. A general dependency graph of parallel workers remains a proposal. The WorkGraph design (repository) is not a shipped scheduler. Use the agent harness and commitments guide for current behavior.The runtime-governance principle
Models interpret requests and propose tool calls. Formation checks the available capabilities, arguments, permissions, budgets, and lifecycle state before executing them. Provider-native tool calls are a request format; they do not transfer execution authority to the provider. See Agent harness, Tools, and Live steering.The capture-before-behavior principle
Durable records connect a response to its trigger, model activity, tool outcomes, and delivery state. Logs and traces help operate the system, while the database provides the run history. Recovery must distinguish recorded outcomes from unknown external effects instead of blindly replaying writes. See Inspect agent activity and Turn checkpoints.The follow-through principle
An agent’s job is to reach the goal, not to report the first obstacle. A single failed tool call, a timeout, or an empty result is an observation to act on, not a terminal condition. Formation agents are expected to be persistent: exhaust the reasonable paths to an answer before returning one that says the work could not be done. This has two distinct layers, and they must not be confused with each other:- Transient-failure retry. A recoverable failure — a timeout, a rate limit, a provider hiccup — is retried with backoff a bounded number of times before the agent concludes the path itself is unavailable. Retrying is cheap relative to giving up on recoverable noise; retrying forever is not. The retry budget is bounded and sized against the run’s remaining allowance so persistence never becomes an unbounded resource drain.
- Change of approach. When a tool is genuinely unavailable after retries,
the agent does not stop; it looks for another authorized way to the same goal.
A failed browser read can fall back to a page-reading provider, a web search,
or an execution environment fetching the content with
curl— as long as the destination, credential, and permission rules still hold. Switching tools never switches off the rules that governed the original attempt.