AI Agents Are More Than Features. They Are a New Operating Model for Work.

Most AI agent discussions still begin with a feature question: what can the agent do?

Draft the response. Summarize the meeting. Update the CRM. Analyze the ticket queue. Generate the test plan. Prepare the campaign. Open the pull request.

That is a reasonable starting point, but it is too small.

The more useful product question is what changes once software can take action inside the work system itself.

For years, SaaS products have mostly been systems of record and systems of collaboration. They stored work, displayed work, routed work, discussed work, and measured work. Humans still carried most of the operating burden: deciding what should happen next, moving between tools, remembering context, checking quality, and knowing when something needed escalation.

Agents change that boundary.

Once software can act, the product is no longer just a place where work is tracked. It becomes part of the work system itself. It needs to know what can be done autonomously, what requires approval, what data can be used, which systems it is allowed to change, when a human needs to be pulled in, and how the organization can audit what happened later.

That is why treating agents as another feature is too small. A chatbot can sit inside an existing workflow. An agent changes the workflow.

The companies that win this phase will not be the ones that add the most AI buttons. They will be the ones that understand the operating model around the agent: the work graph, the context layer, the authority model, the verification loop, the escalation path, and the trust system.

This week’s AI News

This week’s AI News tracks three agent stories worth reading alongside the main piece:

• Asana’s StackAI deal shows agents are moving into the work graph — Asana is buying deeper agent execution capability, but the bigger signal is product architecture: agents become more useful when they can operate inside the project, dependency, ownership, and workflow graph where work already lives.
• OpenAI is turning Codex into a worker, not just a coding tool — Codex is increasingly being framed as a broader delegated-work pattern: context in, bounded execution, human review, and a traceable result. The PM takeaway is that coding agents are becoming an early signal for how agentic work may spread into other knowledge workflows.
• Microsoft Scout points to the desktop as an agent workspace — Scout shows the opposite wedge: instead of starting inside one app, the agent starts closer to the user’s real workspace across files, browser activity, shell, and Microsoft 365 context. That makes the opportunity bigger, but also raises the bar for permissions, verification, and audit.

Together, these stories show the same market shift from different angles: the next agent battle is not just model quality. It is who owns the work environment where agents have enough context, authority, and trust to act.

The agent is not the product. The operating model is.

Most teams still describe agent products in terms of visible tasks: draft the document, update the CRM, analyze the ticket queue, generate the test plan, summarize the meeting, file the claim, create the campaign, open the pull request.

That framing is useful, but it hides the harder question: what must be true around the task for an organization to let software act?

The task is only the visible unit of value. The operating model around the task determines whether the agent can actually be used in a real organization.

Take a simple customer-support example. “Have an agent resolve support tickets” sounds like a feature. But the product questions arrive immediately:

• Which tickets can the agent resolve without human review?
• Which customer segments require stricter approval?
• Which knowledge sources are authoritative?
• Can the agent issue refunds, credits, or only draft recommendations?
• What happens when policy and customer history disagree?
• How is the decision logged?
• How does a manager inspect the agent’s decision trail later?
• How does the system learn from overturned decisions?

The same pattern appears in software development, insurance claims, sales operations, finance workflows, marketing operations, and internal IT. The moment an agent crosses from suggestion into action, the product problem becomes organizational.

This is why work platforms, productivity suites, developer tools, support systems, CRMs, and internal operations products are all starting to face the same design problem. Once agents can participate in work, the product has to coordinate people, systems, approvals, and outcomes.

Different starting points, same destination: agents are becoming part of the operating infrastructure of work.

The six layers of an agent operating model

For product leaders, the practical question is not “should we add agents?” It is “what operating model would make agents useful, safe, and economically viable inside our product?”

A useful way to break this down is six layers.