The next AI platform may not look like a new chat window.

It may look like the meeting room, the CRM record, the service queue, or the low-code builder your team already uses.

That shift is visible in two recent enterprise moves. Cisco announced new Webex experiences where people can invite agents into spaces, meetings, and calls to execute multi-step work across Webex and third-party applications. Microsoft’s October Copilot Studio update brings apps, workflows, and agents into one building environment, with hooks for deterministic controls, reusable enterprise knowledge, evaluations, and a review panel before publishing.

The product announcements are different. The operating implication is the same: AI is moving closer to the system of work, and proximity changes the risk.

The closer the agent gets to the work, the less useful “human in the loop” becomes as a complete control. You need to name the loop: what the agent may see, what it may prepare, what it may change, and who owns the exception.

What happened

Cisco’s Webex announcement describes agents as participants in the work surface, not just assistants sitting beside it. A team can call an analytics agent into a space, retrieve usage information, and ask another agent to update a presentation. Cisco also describes persistent customer context and long-horizon execution through its Dialog experience, with identity, security, governance, telemetry, and observability around the agent layer.

Microsoft is taking a platform-builder route. Copilot Studio now positions apps, deterministic workflows, and adaptive agents as parts of one business solution. Its new hooks can load context at session start, inspect or block tool calls, transform results, and capture consistent telemetry. Foundry IQ can provide reusable enterprise knowledge with citations, while expanded evaluations measure task completion, tool accuracy, safety, and latency. A Review panel surfaces blockers and warnings before publication.

This is more than a feature race. It is a race to own the place where context becomes action—and the defaults that govern that transition.

Why it matters

When an agent lives outside the workflow, the boundary is easier to see. Someone opens a separate assistant, copies in information, reviews the answer, and decides what to do next.

When the agent lives inside the workflow, that separation weakens. The agent can see the meeting context, the customer record, the current document, the process state, or the available tools. That is useful because less context has to be reassembled by hand. It is also dangerous because the agent may inherit more context and authority than the team intended.

The central production question changes from:

Can the model produce a good answer?

to:

What is this agent allowed to know, decide, change, and leave behind?

That question applies whether the agent is embedded in Webex, Copilot Studio, a CRM, a support platform, or an internal tool. The interface is not the governance model. A convenient button can still trigger an unclear permission, an unreviewed write-back, or an evidence gap.

Context is becoming a product surface

Enterprise software used to compete mainly on features and integrations. Agentic software increasingly competes on the quality of the context it can assemble and the actions it can safely take from that context.

That makes the context layer a product surface with its own design decisions:

  • Scope: Which records, conversations, files, policies, and signals are visible?
  • Freshness: How current must the information be before an action is allowed?
  • Provenance: Can the user see which source supported the answer or recommendation?
  • Identity: Is the agent acting as the requesting employee, a service account, or its own governed identity?
  • Action: Which tools may it call, and which calls require approval?
  • Persistence: What does it remember after the meeting, ticket, or session ends?
  • Exit: Where does uncertain or consequential work go when the agent cannot safely finish?

These are not abstract compliance questions. They determine whether the workflow saves time or creates a cleanup queue.

An agent that drafts a follow-up from a meeting is one thing. An agent that updates the customer record, changes a renewal stage, sends a commitment, and opens a billing action is another. The same conversational surface can contain very different levels of business authority.

The operator move: separate context from authority

Teams adopting embedded agents should resist the temptation to approve the whole feature as one unit. Approve context and authority separately. A tool can be useful with broad read access and still be unsafe with one poorly defined write permission.

Start with a small action map:

1. Read: What information may the agent inspect? 2. Prepare: What may it draft, summarize, calculate, or recommend? 3. Request: What action may it queue for a human decision? 4. Act: What may it execute without another approval? 5. Record: What evidence must remain after the run? 6. Escalate: Who owns the case when the context is missing or the stakes change?

This creates a more useful pilot than “turn on the agent and see what happens.” It also lets a team benefit from embedded context without granting embedded authority by default.

For a first deployment, keep the action boundary narrow. Let the agent read approved sources, prepare work, and request a decision. Require a named reviewer for external communication, financial changes, policy exceptions, irreversible updates, or anything that changes a customer promise. Record the source, output, decision, reviewer, and action taken.

Then test one normal case, one incomplete-context case, one conflicting-source case, one high-stakes case, and one case that must be handed to a person. For each case, capture the evidence the agent used, the boundary it reached, the human decision, and the resulting record. The goal is not to prove that the agent never fails. It is to prove that the workflow fails visibly and safely.

The take

Cisco and Microsoft are pointing toward the same market direction from different entry points: agents will increasingly appear inside the places where teams already coordinate, decide, and execute work.

That is good news for adoption. People do not want to rebuild their day around another disconnected assistant.

It is also the point where casual experimentation becomes operating-model design. Once an agent inherits live context and can call tools, the team needs a clear answer for what it can see, what it can do, who reviews it, and what record remains afterward.

The best early question is not “Which platform has the smartest agent?”

Ask instead: Which work surface can give an agent enough context to be useful without giving it more authority than the team can observe, review, and reverse?

That is the boundary that turns embedded AI from a demo into a dependable workflow. If the team cannot answer that question in five minutes, the agent is not ready for live work—no matter how convenient the interface looks.

Sources

  • [Cisco: Cisco Unveils New Agentic Collaboration Experiences](https://newsroom.cisco.com/c/r/newsroom/en/us/a/y2026/m10/cisco-unveils-new-agentic-collaboration-experiences.html)
  • [Microsoft Copilot Blog: Build apps, workflows, and agents together](https://www.microsoft.com/en-us/copilot/blog/copilot-studio/new-and-improved-build-apps-extend-agents-and-transform-business-processes-in-microsoft-copilot-studio/)
  • [Microsoft Learn: Hooks overview for Copilot Studio agents](https://learn.microsoft.com/en-us/microsoft-copilot-studio/agents-experience/hooks-overview)

Suggested CTA: Use the [AI Workflow Approval Readiness Screen](../products/freebies/cortex-ai-workflow-approval-readiness-screen-2026-09-11.md) to separate an agent’s read, prepare, request, act, record, and escalate permissions before a live rollout.

Suggested internal links: [Your AI Workflow Does Not Need More Prompts. It Needs a Control Layer.](2026-10-09-your-ai-workflow-needs-a-control-layer-not-more-prompts.md); [Your AI Workflow Needs a Source of Truth Before Another Connector](2026-09-07-your-ai-workflow-needs-a-source-of-truth-before-another-connector.md); [Your AI Workflow Is Not Governed Until You Can Roll It Back](../research/2026-09-05-ai-workflow-rollback-proof-gap-demand-read.md).