Lesson 3 of 12 · Operating model

Establish an operating model

Agents are software plus operations plus risk. Without clear ownership, teams ship unsafe capabilities, approvals become political, and production incidents have no playbook. A workable operating model is the difference between an experiment and a program.

A cross-functional AI product team

At minimum:

  • Product owner: business outcomes and prioritization.
  • Domain expert: SOPs, edge cases and acceptance criteria.
  • LLM or agent engineer: prompting, tool schemas and evaluations.
  • Platform engineer: connectors, identity, environments and deployment.
  • Security: threat model, access, secrets and logging.
  • Legal, risk and compliance: policies, approvals and audit posture.

Three patterns

  • Central platform team with federated delivery (recommended): shared guardrails and tooling; domain squads ship agents.
  • Fully centralized AI factory: good for early control, can become a bottleneck.
  • Fully federated: fast, but risky without strong standards and shared infrastructure.

A crisp RACI

The key is clear ownership of tool integrations, permissions and credential scopes, model and version changes, safety policy updates, and incident response and rollback.

An operating model is the difference between an experiment and a program.

Check your understanding

3 questions. Pick an answer for each, then check. Nothing leaves your browser session.

1. Which operating pattern does the article recommend?

2. What is the weakness of a fully centralized AI factory?

3. In a RACI, how many roles should be accountable for a decision?

Answer every question to check.
An unhandled error has occurred. Reload ๐Ÿ—™

Reconnecting…

Your connection to Agent Adoption Lab dropped, probably a Wi-Fi blip. Hold on while it reconnects. Your inputs are kept.

The connection could not be restored. The page will reload in a few seconds.