Agent Systems

This section exists because “AI agents” is now too broad to be useful. Real teams need to decide where tools belong, how autonomy should be constrained, when MCP helps, and what governance is required before agents touch internal systems or customer-facing workflows.

Core paths

Model Context Protocol for enterprise teams Use this page to decide when MCP is a genuine architecture advantage and when normal function calling is still enough.

Agent workflows vs autonomous agents Use this page to separate deterministic workflow design from open-ended autonomy before the team overbuilds.

MCP security and approval boundaries Use this page to decide how tool permissions, approval gates, and risk classes should work before MCP reaches production.

Remote MCP servers vs direct tool integrations Use this page when the team needs to choose between shared MCP infrastructure and simpler app-owned tool wiring.

Built-in tools vs external integrations Use this page when the real architecture choice is vendor-managed tools, app-owned internal APIs, or a deliberate hybrid model.

Computer Use API vs browser automation Use this page when browser-facing agents need a clearer boundary between UI interpretation and deterministic automation.

User-scoped auth vs service accounts Use this page when the real boundary is whose authority the agent is using, not just which tool it can call.

Tool timeouts, retries, and idempotency Use this page when agent reliability and repeated side effects are now control-plane problems rather than prompt problems.

Sandboxing, network permissions, and secrets Use this page when coding-agent execution boundaries need to separate safe repository work from broader system risk.

Model routing Routing remains essential once the agent stack grows beyond one model lane or one risk class.

Prompt release governance Agent systems still need release control, rollback logic, and review discipline.

Questions this section is built to answer

When does an agent actually need tool access, retrieval, or MCP integration?
When should the system stay workflow-first instead of pretending autonomy is the product?
Which parts of an agent design create the real risk: model choice, tool permissions, or approval boundaries?
How should teams stage agent adoption so they gain leverage without creating hidden operating risk?

High-value current cluster

MCP architecture decision Start here to decide whether MCP belongs in the architecture at all.

MCP security boundary A stronger implementation page around approval, read-versus-write tools, and user-scoped versus system-scoped access.

Remote MCP adoption boundary A higher-intent page for the moment when MCP interest turns into a real shared-tool platform decision.

Built-in tools vs owned tool boundaries A stronger architecture page for teams deciding how much agent capability should be vendor-managed versus internally owned.

Computer use versus browser automation A current high-intent page for teams deciding whether browser-facing agents need model-driven UI understanding, deterministic automation, or a hybrid control plane.

User authority versus system authority A high-intent control page for teams deciding when agents should inherit user scope and when a service identity is more appropriate.

Retries, timeouts, and idempotency A practical reliability page for teams trying to stop retry logic from turning tool failures into repeated side effects.

Sandboxing and secret boundaries A higher-intent control page for engineering teams deciding how much filesystem, network, and credential access coding agents should ever receive.