Agentic AI and the Product Manager

Most AI features shipped so far have been single-turn: a prompt goes in, text comes out.

Agentic systems are different. The model decides what to do next, calls tools, observes results and continues until it reaches a stopping point.

What an agent actually is

An agent is usually a loop:

1. the model receives a goal and a set of available tools
2. it chooses a tool and calls it
3. the result is added to its context
4. it repeats until the goal is met or a limit is hit

Nothing about that loop is exotic. What makes it hard is everything around it.

The product questions change

Once a system can act rather than just answer, the product questions shift:

• What is this agent allowed to do without asking?
• What requires human approval?
• What happens when a tool call fails halfway through?
• How does a user understand what the agent did?
• How do we audit a run after the fact?

These are product decisions, not model decisions.

Permissions are the real design surface

The most useful mental model is least privilege. An agent should hold the narrowest set of capabilities that lets it finish the job.

That means being deliberate about:

• which tools are exposed at all
• which tools are read-only versus write
• where a human sits in the loop
• how long a credential or session lives

Where this is going

Tool use is becoming standardised — MCP is the clearest example — which means the differentiator is no longer whether you can wire a model to a tool.

It is whether you can do it safely, legibly and repeatedly inside an enterprise.

An example: a support workflow

Imagine an assistant that reads a support ticket, retrieves account information and drafts a response. Reading the ticket and preparing a draft can have different approval requirements from issuing a refund or sending the message.

The workflow should make that boundary explicit. A failed account lookup should leave a clear status and a recoverable draft. Retrying a tool call should not accidentally issue the same refund twice. The user should be able to see which steps completed and which still need a decision.

This is an illustrative workflow, rather than a reported deployment. It shows why permissions, recovery and user feedback belong in the product specification alongside the agent’s goal.

The MCP architecture documentation explains how applications connect to servers that expose tools and context. A standard connection does not decide which business actions your product should allow; those boundaries still need to be designed for the workflow.