Platform principles

1. One platform, multiple ways to interact

Everyone should be able to use the same platform, from simple conversations to complex engineering work.

Implications: Support the UI, CLI, and Terraform alongside chat, APIs, and interactive developer tools. Use shared Agent and Task concepts across interfaces. Avoid separate platforms for different user groups.

2. Use organizational models that work for agents and humans alike where possible

Agents should participate in existing and new workflows and collaborate with humans and other agents as team members, wherever practical.

Implications: Reuse or create concepts for identity, ownership, and collaboration. Introduce agent-specific mechanisms only where necessary, so the organization remains easy to reason about.

3. Tasks outlive interactions

Tasks should continue independently of the interface or the user’s presence. Sessions provide the execution needed to complete them.

Implications: Persist Tasks and their status. Support remote Sessions, retries, and pause/resume where applicable. Allow people to inspect progress, review results, and reconnect to an interactive environment.

4. Sessions are isolated by default

Sessions have explicit access boundaries. Who can view, continue, or fork a Session depends on its purpose, ownership, and sharing settings.

Implications: Isolate personal Sessions by default. Support explicit sharing with appropriate levels of access, including read-only, forking, and collaboration.

5. Policies bound autonomy

Agents may act independently only within explicit Policies and their delegated authority.

Implications: Define permitted actions, approvals, and limits on permissions, time, and cost. Support stopping Tasks, terminating Sessions, and revoking Delegation Grants.

6. Tools are shared

Agents use shared Tools. Connections provide configured, authenticated access to external systems based on execution authority. Connection credentials are not available directly to the agent.

Implications: Maintain a catalog of Tools and Connections. Prefer standard interfaces such as MCP. Keep system-specific business rules and access controls in the systems that own them.

7. Buy commodity, build business-specific capabilities

Engineering effort should focus on capabilities that create value specific to the business.

Implications: Build custom tools and platform components only where justified. Evaluate the total operating and maintenance cost, not just the initial build.

8. Keep components replaceable

Adopt better technology without rebuilding everything around it. Avoid unnecessary dependence on specific models, vendors, and frameworks, while accepting lock-in when the benefits outweigh the costs.

Implications: Prefer shared industry and foundation-governed specifications at integration boundaries: MCP for tools, OpenAPI for HTTP API contracts, OpenID Connect and OAuth for identity and access, and OpenTelemetry for telemetry. Use portable schemas and records, document version and capability requirements, and test replacements. Avoid hasty abstractions; accept specific dependencies when their benefits justify the switching cost.

Explore the standards and portability approach →

9. Ownership and quality are explicit

Every Agent, Task, and Capability must have clear human accountability.

Implications: Assign Agent Owners, Task Owners, Platform Owners, and Capability Owners. Measure quality, failures, usage, and cost. Maintain audit records.

10. Make the safe path the easy path

Teams should be able to create, deploy, and operate Agents without unnecessary central coordination, while common controls remain enforceable.

Implications: Provide self-service configuration, templates, approved Tools and Connections, and standard Policies. Let owners manage their scope of responsibility.