> ## Documentation Index > Fetch the complete documentation index at: https://docs.formation.texturehq.com/llms.txt > Use this file to discover all available pages before exploring further. # Design principles > Why Formation keeps identity, context, capabilities, and execution explicit. Formation is designed for conversations involving several people and agents. It needs to preserve who said something, who should hear the answer, and which agent owns the work. These principles explain that design; feature guides describe what is implemented and how to use it. ## 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](/runtime/identity-linking.md) and [Agent provisioning](/agent-provisioning.md). ## 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](/perspective.md) and [Memory privacy](/runtime/memory-privacy.md). ## 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](/data-model.md) and [Context resolution](/runtime/context-resolution.md). ## 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](/runtime/addressing.md). ## 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](/operations/installation.md) and [Versioned state](/versioned-state.md). ## 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](/runtime/tools.md) and [Sandboxed execution](/runtime/sandboxed-execution.md). ## 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](/layers.md) and [Model connectors](/connectors/model.md). ## 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)](https://github.com/TextureHQ/formation/blob/main/docs/runtime/work-graph.md) is not a shipped scheduler. Use the [agent harness](/runtime/agent-harness.md) and [commitments guide](/runtime/commitments.md) 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](/runtime/agent-harness.md), [Tools](/runtime/tools.md), and [Live steering](/runtime/live-steering.md). ## 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](/runtime/observability.md) and [Turn checkpoints](/runtime/turn-checkpoints.md). ## 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. Persistence is bounded, not reckless. It stops at real limits: a withdrawn permission or cancellation, an exhausted allowance, or paths that are genuinely exhausted. When the agent does stop, it preserves earlier successful work and explains the concrete remaining obstacle or returns a useful verified partial answer — never a bare "it failed." An error surfaced to a person is the last resort after the reasonable alternatives are spent, not the first reflex after one attempt. This is a behavioral contract on the agent loop, not a property any single infrastructure layer provides. Durable execution can retry an eligible activity and resume a run after worker loss, but it does not choose the alternate tool; the agent loop owns that policy. See [Agent harness](/runtime/agent-harness.md) for the bounded run, budgets, and recovery boundaries, and the [recovery and agent persistence section of the Temporal execution plan (repository)](https://github.com/TextureHQ/formation/blob/main/docs/roadmap/temporal-execution.md#recovery-and-agent-persistence) for the failure-disposition model this principle drives. The engineering guardrails and historical planning material remain in the [roadmap (repository)](https://github.com/TextureHQ/formation/blob/main/docs/roadmap.md#design-guardrails). They guide development; they are not a feature availability list. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.