Writing

The Missing Product Lens for Agentic AI

A design-system lens for reasoning about agents in delivery systems and agents inside products.

Agents in the Delivery System, Agents in the Product System

Abstract

Agentic AI is often discussed as a way to help teams work faster: coding assistants, DevOps agents, platform copilots, incident helpers, and workflow automation. That conversation is valid, and necessary - but it is only one lens.

There is a second lens that is less clearly articulated: how we design software products and services where agents are part of the system itself.

In that world, the important question is not “Where can we add an agent?”

It is “What user or organisational problem are we trying to solve, and does agentic behaviour help?”

This article separates those two conversations. It introduces the Delivery System Lens for thinking about agents that help teams build and operate software, and the Product System Lens for thinking about agents embedded inside products and services. It then proposes a set of design dimensions that help teams reason about agentic capabilities before rushing to name agent types, pick models, or add chat interfaces.

The goal is not to create a definitive taxonomy. It is to give product, design, engineering, platform, security, and leadership teams a clearer language for discussing agentic systems before they build the wrong thing well.

Background Context

The thinking in this document was prompted by the Northern DevOps & Platform Conference, organised by Community Stack in Leeds on the 19th May 2026. A lot of the conversation there naturally sat within what I would describe as the Delivery System Lens for agentic AI: how agents, platforms, and AI-assisted workflows help teams build, operate, and improve software more effectively.

That framing makes complete sense. It was a DevOps and Platform Engineering conference, the opening keynote was from Matthew Skelton, author of Team Topologies, and many organisations are still wrestling with the fundamentals of effective software delivery: cognitive load, team boundaries, platform capabilities, flow of change, and the reliable delivery of value. In that context, Team Topologies remains a highly relevant model for organisational Delivery Systems.

But the conference also helped solidify a separate thought for me. Alongside the delivery-system conversation, there is another conversation that was less clearly articulated: the Product System Lens for agentic AI. Not how agents help us build products, but how we design products and services that have agentic AI embedded within them.

This is not to say that “product knowledge” does not exist. It clearly does. Tools like Cursor, GitHub Copilot, Claude Code and others are already demonstrating what good product experiences around AI-assisted and agentic workflows can look like. The gap is not a lack of examples. The gap is a lack of shared language for describing the product architecture: how these capabilities are embedded, how users interact with them, what autonomy they have, what data they depend on, and how they should be designed, governed and operated.

Put simply:

• The Delivery System Lens asks: how do agents help teams deliver better software?
• The Product System Lens asks: how do we build better software products with agents inside them?

Those two questions are related, but they are not the same question.

Two lenses for agentic AI

The term “agentic AI” is already carrying a lot of weight. Depending on the context, it can mean a coding assistant, an incident response helper, a customer-facing chatbot, a background workflow, a tool-calling LLM, a collection of specialist agents, or a product feature that quietly does complex work on behalf of a user.

That breadth is part of the problem. We are using one phrase to describe several different things.

One way to reduce the confusion is to separate the conversation into two lenses.

The first is the Delivery System Lens. This is concerned with how teams build, run, support, and evolve software. In this lens, agents sit around the product. They help people understand systems, write code, review changes, diagnose incidents, improve documentation, operate platforms, or reduce friction in the path to production.

The second is the Product System Lens. This is concerned with how agents become part of the product or service itself. In this lens, agents sit inside the product. They process data, assist users, co-ordinate workflows, enrich cases, make recommendations, produce outputs, and sometimes act on behalf of the user or organisation.

These lenses overlap in practice. A team may use AI tools to build a product that itself contains AI agents. A user organisation may change its way of working because a new agentic product allows work to be organised differently. A platform team may provide shared agent runtimes that support both internal delivery tooling and customer-facing products.

In spite of the overlap, the distinction still matters. Without it, we risk overlooking fundamental decisions.

The Delivery System Lens

The Delivery System Lens is where much of the current discussion around agentic AI naturally sits. Especially as organisations look to apply what Software Development teams have been doing for a number of years now.

In this lens, the question is not “what product capability are we creating?” but “how does AI change the way teams deliver and operate software?”

This includes familiar uses of AI tooling:

• Coding assistants that help engineers move through implementation faster
• Platform assistants that guide teams through internal developer platforms
• Incident agents that help interpret logs, alerts, dashboards, and runbooks
• Architecture assistants that help teams reason about trade-offs
• Test and quality agents that help identify risks, generate cases, or review coverage
• Documentation agents that help surface internal knowledge
• Onboarding agents that help new team members understand systems and practices

These agents may be simple or sophisticated. Some operate like copilots. Some behave more like workflow assistants. Others may become internal services that teams invoke through chat, APIs, or platform interfaces.

What they have in common is that they are part of the delivery system. They exist to improve the way teams work.

This is why Team Topologies is such a natural reference point. It gives us a way to think about team boundaries, cognitive load, platform capabilities, enabling support, and the flow of change through an organisation. Those concerns remain important in an agentic world. If anything, they become more important, because agents can either reduce organisational friction or amplify it.

A poorly designed agent can create another tool for teams to learn, another place where knowledge is hidden, another source of unreviewed change, or another dependency that nobody clearly owns. A well-designed agent can reduce toil, make expertise more available, shorten feedback loops, and help teams stay focused on the work that creates value.

The delivery question is therefore a socio-technical question:

How do we design agents so that they improve the flow of work through teams and platforms?

Team Topologies helps with that question because it already gives us useful language for the delivery system. It encourages us to think about the shape of teams, how they interact, how much cognitive load they carry, and where platform capabilities should sit.

An agent that supports a stream-aligned team should probably be judged by whether it helps that team deliver value safely and independently. An agent that belongs to a platform team should probably be judged by whether it makes self-service easier and reduces unnecessary interaction. An agent used by an enabling team should probably be judged by whether it helps transfer capability, not whether it becomes a permanent dependency.

This is a strong and necessary conversation. It is not a distraction from the real work. Organisations still struggle to deliver software well. Tooling alone does not fix unclear ownership, overloaded teams, poor platform design, or weak feedback loops.

Agentic AI may help, but only if it is introduced with an understanding of how work actually moves through the organisation.

The Product System Lens

The Product System Lens asks a different question.

It is not primarily concerned with how the team builds, operates, or supports software. It is concerned with the product itself.

In this lens, an agent is part of the product’s capability model. It may be visible to the user, hidden behind a normal interface, or operating in the background. It may answer questions, synthesise documents, enrich a case, investigate a problem, make a recommendation, co-ordinate specialist capabilities, or trigger an action in another system.

The product may still look conventional. There may be forms, dashboards, tables, search results, case views, task lists, and approval screens. The user may not think they are “using an agent”. They may simply be using a product that can do more complex work than products could previously do. This distinction is important.

A customer support product with an AI assistant in the corner is one kind of agentic product. A case management system that uses background agents to triage, enrich, and recommend next actions is another. A cyber security product that sends specialist agents to explore graph data, breach data, OSINT sources, and internal telemetry is different again.

These systems should not all be treated as the same product pattern.

They differ in how users interact with them, what data they process, how long they run for, what outputs they produce, how much autonomy they have, what context they require, and what happens when they are wrong. Those differences matter architecturally.

If an agent only answers a user’s question, the main concerns may be relevance, latency, grounding, clarity, and safe response generation. If an agent changes system state, the concerns expand to include authorisation, validation, audit, rollback, and human approval. If an agent runs for hours across multiple tools and data sources, the concerns expand again to include durable execution, checkpoints, observability, cost control, recovery, and task state.

The Product System Lens therefore needs a different kind of language. It needs to describe agents as product capabilities, not just as productivity aids.

The product question is:

How do we design agentic capabilities that create value for users while remaining understandable, operable, and appropriately constrained?

That is not answered by saying “we have an agent”. It is not answered by adding a chat interface. It is not answered by giving a model access to tools. Those may be implementation choices. They are not the product architecture.

Why the distinction gets blurred

The distinction between the Delivery System Lens and the Product System Lens is easy to state, but harder to keep clear in real organisations.

A useful example is a product designed to help civil servants synthesise documents using government statistics, policy information, organisational knowledge, and other supporting material.

At first glance, we might describe this as an agentic document synthesis product. That is true, but incomplete.

There are several systems in play.

First, there is the user organisation’s delivery system.

Civil servants already have ways of producing documents, reviewing evidence, managing approvals, sharing drafts, applying policy constraints, and maintaining accountability. Introducing an agentic product into that environment changes the work. It may speed up some tasks, change where review is needed, alter the role of subject matter experts, or make previously difficult synthesis work more repeatable.

Second, there is the product system itself.

The product needs to process documents, statistics, organisational context, user intent, policy constraints, and output requirements. It needs to decide what to retrieve, what to summarise, what to challenge, what to cite, what to leave alone, and how to present uncertainty. It may need to orchestrate multiple agents or workflows behind the scenes.

Third, there is the relationship between the product and the organisation.

The product should support the desired operating model rather than cut across it. If civil servants need traceability, the system must make traceability natural. If approval is required, the product should not hide the work that needs review. If policy interpretation needs expert judgement, the agent should not pretend to replace that judgement. Product design and organisational design meet at this boundary.

Fourth, there is the delivery system of the product team building the product.

That team may itself be using AI tools, platform capabilities, agentic development workflows, and modern delivery practices to build and operate the service. The team needs its own approach to discovery, engineering, testing, evaluation, security, deployment, and support.

This is why conversations about agentic AI often become muddy. People may be talking about different systems at the same time.

One person is talking about how agents help delivery teams move faster. Another is talking about how agentic features should appear to end users. Another is talking about governance, approval, and operating model. Another is talking about model orchestration, context management, tool use, and evaluation.

All of these are valid conversations. They are just not the same conversation.

This matters because unclear framing leads to weak decisions.

If we treat a product-system problem as a delivery-system problem, we may over-focus on productivity and under-design the actual user experience. If we treat a delivery-system problem as a product-system problem, we may build something clever that does not fit into the way teams work. If we ignore the bridge between the product and the organisation, we may create systems that are technically impressive but operationally awkward.

The goal is not to separate these concerns forever. The goal is to know which lens we are using at any given moment.

Product system agents need dimensions before they need names

There is a temptation to move quickly from “we need better product architecture language” to “let’s define the types of agents”.

That may be useful eventually, but it is not the best starting point.

The Product System Lens needs a taxonomy, but the first step is not to name every possible type of agent. The first step is to define the dimensions that make one agent meaningfully different from another. Once those dimensions are clear, we can identify recurring categories or archetypes.

This matters because agent categories can be misleading if they arrive too early.

For example, calling something an “assistant agent” may tell us that it interacts with a human, but it does not tell us whether it can call tools, change data, delegate work, run for a long time, or operate over untrusted information. Calling something a “workflow agent” tells us that it progresses a task, but not whether it is visible to the user, interruptible, auditable, or capable of acting autonomously.

Names help us communicate. Dimensions help us design.

A useful product architecture model should help teams ask better questions before they settle on a pattern. It should help a team understand what kind of agentic capability they are building, what risks come with it, and what system properties it will need.

The following dimensions are not intended to be complete. They are a starting point for describing product agents more precisely.

1. Mode of interaction: How is the agent invoked, experienced, and controlled?

2. Variety and quality of data: What kind of information environment is the agent operating in?

3. Required context: What context is needed to do useful work, and how should that be bounded?

4. Breadth of capabilities: What is this agent allowed to do, and what should remain outside its boundary?

5. Length and shape of execution: Is this a response, a workflow, a durable task, or an ongoing process?

6. Output format and contract: What is the agent producing, and what responsibility does that output carry?

7. Autonomy and delegation: Where does the agent have discretion, and where must control remain explicit?

8. Interruptibility and resumability: Can the work be paused, inspected, redirected, and safely resumed?

9. Model and runtime requirements: What runtime does this agentic capability need in order to meet its product responsibilities?

10. Security and trust boundaries: What are the trust boundaries around this agentic capability, and how are identity, access, data, tools, outputs, and agent-to-agent interactions controlled?

Dimension 1: Mode of interaction

The first question is on how the user, system, or another agent interacts with your agent.

Some agents are conversational. A user asks a question or gives an instruction, and the agent responds in natural language. This is the pattern most people recognise, partly because chat interfaces have become the default mental model for AI-assisted products.

Other agents are invoked through product workflows. The user may click a button, complete a form, upload a document, assign a case, or request an analysis. The agent is part of the workflow, but the experience does not need to feel like a conversation.

Some agents are event-driven. They react to something that has happened in the system: a new case, a failed deployment, an unusual transaction, a changed document, a security signal, or a threshold being crossed.

Others are scheduled or continuous. They run periodically, monitor for changes, enrich data, or maintain a view of the world over time.

This dimension matters because interaction mode shapes the user experience, error handling, latency requirements, and control model.

A conversational agent can ask clarifying questions. A background agent cannot always do that. A workflow agent may need to fit into existing product screens. An event-driven agent may need to make progress without immediate human input.

The design question is:

How is the agent invoked, experienced, and controlled?

Dimension 2: Variety and quality of data

Agents differ significantly in the data they process.

Some work mostly with clean, structured data. Others work with documents, emails, logs, transcripts, images, source code, graph data, operational telemetry, web content, or a mixture of internal and external sources.

The variety of data matters, but so does completeness.

An agent working with a curated knowledge base has a different job from an agent working with partial, inconsistent, or conflicting information. A product that summarises approved policy documents has a different risk profile from one that investigates open-source intelligence, user-submitted material, or unverified third-party data.

This is especially important in agentic systems because agents are often most useful where information is fragmented. They can search, compare, summarise, reconcile, and produce a view that would otherwise take a person significant effort to assemble.

But the more incomplete or untrusted the data, the more care is needed.

The system may need to preserve provenance, show confidence, identify gaps, avoid overclaiming, and make uncertainty visible. It may need to separate facts from interpretations. It may need to avoid treating retrieved content as instructions. It may need to explain why one source was preferred over another.

The design question is:

What kind of information environment is the agent operating in?

Dimension 3: Required context

A simple agent may only need the current prompt and a small amount of retrieved information.

A more capable product agent may need much more context: user intent, product state, organisation rules, historic decisions, previous task outputs, domain constraints, permissions, and the current stage of a workflow. Context is often where agentic products become difficult.

Too little context and the agent cannot produce useful work. Too much unmanaged context and the system becomes expensive, slow, noisy, or unsafe. Poorly selected context can be worse than no context because it gives the model confidence without relevance.

Context is not just a prompt engineering problem. It is a product architecture problem.

Teams need to decide what context is available, who is allowed to access it, how it is retrieved, how long it persists, how it is scoped to the task, and how it is inspected. They also need to consider whether context belongs to the user, the organisation, the workflow, the product, or the agent.

In multi-agent systems, context becomes even more important. Specialist agents may need different views of the same task. An orchestrating agent may need to know what has been attempted, what failed, and which agent is best placed to continue. A governance agent may need access to evidence that the producing agent did not include in its final output.

The design question is:

What does the agent need to know to do useful work, and how should that context be bounded?

Dimension 4: Breadth of capabilities

Not all agents have the same capability breadth.

Some agents answer questions. Some retrieve information. Some analyse, summarise, classify, compare, or generate structured outputs. Some call tools. Some update product state. Some co-ordinate with other agents. Some decide which path a workflow should take.

This breadth matters because every additional capability changes the system boundary.

An agent that only reads data has one risk profile. An agent that writes data has another. An agent that can call external tools introduces new concerns around permissions, rate limits, cost, security, and unintended side effects.

An agent that can delegate work introduces questions about task ownership, traceability, and failure handling.

Breadth of capability should therefore be a deliberate design choice, not a side effect of what the underlying model or framework can do.

There is often value in keeping agents narrow. A specialist agent with a well-defined role, clear inputs, known tools, and constrained outputs can be easier to test and operate than a broad agent that can attempt many different tasks. The right level of breadth depends on the product problem, the risk profile, and the surrounding system design.

The design question is:

What is this agent allowed to do, and what should remain outside its boundary?

What is this agent allowed to do, and what should remain outside its boundary?

Dimension 5: Length and shape of execution

Some agents complete their work in a single response. Others run through a multi-step workflow. Some may need minutes, hours, or longer. Some may run continuously in the background.

Length of execution changes the architecture.

A short synchronous interaction may fit comfortably inside a request-response pattern. A longer task may need durable execution, task state, progress updates, retries, cancellation, and recovery. A task that depends on human approval may need to pause and resume. A background agent may need scheduling, idempotency, monitoring, and clear ownership of its outputs.

This is one of the places where product agents start to look less like chatbots and more like distributed systems.

If an agent is doing meaningful work over time, the system needs to know what it is doing, what it has already done, what it plans to do next, what tools it has called, what evidence it has gathered, and how to recover if something fails.

A product may also need to show this state to the user. That does not necessarily mean exposing every internal step, but users often need enough visibility to trust the process, understand progress, and intervene when needed.

The design question is:

Is this a response, a workflow, a durable task, or an ongoing process?

Dimension 6: Output format and contract

Agents produce different kinds of outputs.

Some produce natural language. Some produce structured data. Some produce summaries, recommendations, classifications, risk scores, plans, documents, decisions, or actions. Some produce intermediate outputs for other agents rather than final outputs for humans.

The output type matters, but the output contract matters more. A casual summary has a different contract from a regulated decision. A recommendation has a different contract from an action. A generated document has a different contract from an audit record. A classification used to route work has a different contract from a message shown to a user.

Product teams need to be clear about what the output is for.

Is it advisory? Is it evidence? Is it a draft? Is it a decision? Is it an instruction to another system? Does it need to be explainable? Does it need to be repeatable? Does it need to be approved before use? Does the user need to see sources, confidence, or reasoning? Does the organisation need an audit trail?

Without a clear output contract, agentic products can become difficult to trust. Users may not know whether they are looking at a suggestion, a conclusion, or an action that has already taken effect.

The design question is:

What is the agent producing, and what responsibility does that output carry?

Dimension 7: Autonomy and delegation

Autonomy is not a single setting. It is a set of choices about what the agent can decide and where human or system control is required.

An agent may have no autonomy beyond generating a response. It may be allowed to choose retrieval strategies, call tools, select workflow steps, ask another agent for help, or decide when it has enough evidence to produce an output. It may be allowed to act only after approval. It may be allowed to act within a narrow policy boundary. It may be allowed to run independently unless it hits an exception.

Delegation adds another layer.

In multi-agent systems, an agent may be able to discover specialist capabilities, assign subtasks, review outputs, and combine results. This is where protocols and patterns such as A2A become relevant. The question is not only whether one agent can complete a task, but whether the system can co-ordinate work across multiple agents with different roles.

Autonomy and delegation are powerful, but they change the accountability model.

If an agent delegates work to another agent, who owns the result? If a delegated agent fails, how is that failure surfaced? If two agents disagree, how is that resolved? If an orchestrating agent chooses the wrong specialist, is that a product issue, a model issue, or an operating model issue? These are not abstract questions. They affect audit, testing, observability, and user trust.

The design question is:

Where does the agent have discretion, and where must control remain explicit?

Dimension 8: Interruptibility and resumability

Many product agents will need to support interruption.

A user may need to stop a task, correct an assumption, provide missing information, approve a step, reject an output, or ask the agent to try a different path. The system may need to pause because a dependency is unavailable, a policy threshold has been reached, or a human decision is required.

This is straightforward in a simple chat interaction. It is more complex in a long-running or multi-agent workflow.

To resume well, the system needs durable task state. It needs to know what has already happened. It needs to avoid repeating unsafe actions. It needs to preserve enough context for the agent to continue without starting again. It may need to show the user a meaningful summary of the current state before asking them to decide what happens next.

Interruptibility is also part of user control.

If an agent is doing work on behalf of a user, the user should understand when they can intervene and what effect that intervention has. A product that offers no meaningful way to stop, correct, or inspect an agent may feel efficient when it works, but brittle when it does not.

The design question is:

Can the work be paused, inspected, redirected, and safely resumed?

Dimension 9: Model and runtime requirements

The model is not the agent, but model choice still matters.

Some product agents can be served by smaller, cheaper, faster models. Others require stronger reasoning, larger context windows, multimodal capability, tool use, or model routing. Some need low latency. Some need low cost at high volume. Some need to run in a particular region or environment because of data constraints. Some may need different models for different parts of the workflow.

This is better treated as a consequence of the product design rather than the starting point.

A team should not begin with “which model should we use?” and then discover the product shape afterwards. It is usually better to understand the interaction mode, data boundary, context needs, capability breadth, execution shape, and output contract first. Those choices will narrow the runtime options.

Model and runtime choices also affect operating concerns. A long-running investigation agent using a high-capability model has different cost and observability needs from a short classification agent running at high volume. A product using external model providers has different data and resilience considerations from one using local or private deployment.

The design question is:

What runtime does this agentic capability need in order to meet its product responsibilities?

Dimension 10: Security and trust boundaries

Security appears throughout the other dimensions, but agentic systems make it important enough to consider directly.

A product agent does not simply respond to a user. It may access data, retrieve context, invoke tools, change product state, delegate work to other agents, or produce outputs that influence decisions. Each of those behaviours creates a trust boundary.

Teams need to decide who or what is allowed to interact with the agent, what the agent is allowed to see, what it is allowed to do, and how those permissions change when the agent is acting on behalf of a user, a system, or another agent.

This includes user permissions, agent permissions, tool permissions, data access, output visibility, model access, and third-party service constraints. It also includes agent-to-agent communication. If one agent discovers or invokes another, the system needs a way to know what that agent is, what it is allowed to do, whether it can be trusted, and whether its outputs should be accepted.

This becomes more complex when agents operate over untrusted data. A document, web page, email, ticket, log entry, or external source may contain content that looks like information but behaves like an instruction. Agentic products need to treat data, tools, context, and other agents as things that may be wrong, stale, compromised, over-privileged, or malicious.

Security is also shaped by the surrounding environment. Data residency, privacy requirements, regulatory constraints, organisational policy, customer agreements, and operational risk may determine what models can be used, where agents or the models they use can be run, which third-party services are acceptable, and what information can leave the organisation’s boundary.

The design question is:

What are the trust boundaries around this agentic capability, and how are identity, access, data, tools, outputs, and agent-to-agent interactions controlled?

From dimensions to archetypes

Once we have dimensions, we can start to identify recurring product-agent archetypes.

These archetypes are not rigid categories. They are patterns that emerge from combinations of attributes. A real product may contain several of them. A single agent may move between patterns as it gains capabilities. The point is not to force everything into neat boxes. The point is to create enough language for teams to reason together.

1. An Assistant Agent is directly experienced by a user. It may answer questions, help complete a task, explain information, or guide the user through a product. It is usually visible, often conversational, and commonly produces natural language outputs. The risk increases when it moves from advice to action.

2. A Workflow Agent progresses a defined task or business process. It may gather information, apply rules, call tools, generate structured outputs, and ask for approval at key points. It is useful where the work has shape, but still requires judgement or adaptation.

3. An Embedded Capability Agent sits behind a normal product interface. The user may click “analyse”, “summarise”, “enrich”, or “recommend”, without feeling that they are having a conversation with an agent. This pattern is likely to become common because many users do not want to chat with software. They want the product to help them get work done.

4. A Background Agent runs on a schedule, event, or trigger. It may monitor, classify, enrich, detect, reconcile, or prepare work for later human review. This pattern can be valuable, but it needs strong observability and clear ownership because users may not be watching it run.

5. An Investigation Agent explores incomplete or fragmented information to build evidence, insight, or a conclusion. It may search across multiple sources, compare signals, follow leads, and produce a reasoned output. Cyber security, fraud, compliance, operational diagnostics, and research-heavy domains are natural fits for this pattern.

6. An Orchestrating Agent co-ordinates work across tools, workflows, or other agents. It may decompose a task, select specialists, manage progress, combine outputs, and decide what to do next. This is where agentic systems start to look like distributed product architectures rather than isolated AI features.

7. A Governance or Evaluation Agent reviews, checks, challenges, scores, routes, or constrains outputs. It may assess policy compliance, detect risk, validate evidence, or decide whether escalation is needed. This pattern should not be treated as a magic safety layer, but it can be useful when designed as part of a broader control system.

These archetypes are early language, not a finished taxonomy.

The more useful discipline is to describe an agent through the dimensions first, then decide whether it resembles an archetype. For example:

This is a background investigation agent. It runs asynchronously, operates over incomplete and partially untrusted data, uses specialist tools, can delegate subtasks, produces evidence-backed recommendations, and must support human review before any action is taken.

That description is more useful than simply saying “we have an AI agent”.

It gives product managers, designers, engineers, security specialists, and operators something concrete to discuss.

What this means for product teams

The Product System Lens changes the questions a product team should ask. The starting point should not be “where can we add an agent?” It should be “what user or organisational capability are we trying to create, and does agentic behaviour help?”

Agentic AI is most interesting where the product needs to operate across ambiguity, context, tools, and changing information. It is less compelling where the work is already deterministic, well understood, and better served by simple software.

For product teams, useful questions include:

• What job is the user trying to get done?
• Where does the agent sit in that journey?
• Is the agent visible, hidden, or partly visible?
• What data does it need, and how reliable is that data?
• What decisions is it allowed to make?
• What actions is it allowed to take?
• When should a human be involved?
• What should the user be able to inspect or correct?
• What happens when the agent is uncertain?
• What happens when it is wrong?
• How will we know whether it is performing well?
• What needs to be logged, evaluated, and governed over time?

These questions are product questions and architecture questions at the same time.

That is one of the defining features of agentic products. The user experience, system design, operating model, data architecture, and control model are tightly connected. If one is weak, the others are affected.

For example, if a product hides too much of the agent’s work, users may not trust it. If it exposes too much, users may be overwhelmed. If it asks for approval too often, it may not create enough value. If it acts without approval, it may create unacceptable risk. If it cannot explain its output, it may be unusable in a domain where evidence matters.

This is why agentic product design needs more than prompt engineering. It needs careful product thinking, strong engineering, and a clear understanding of how the capability will sit inside real work.

Where Team Topologies still matters

A Product System Lens does not make Team Topologies less relevant.

In many cases, it makes the surrounding team design more important. Once agentic capabilities become part of a product, teams still need to own them, operate them, improve them, and support users when they fail. The question is where those responsibilities sit.

A stream-aligned team may own an agentic capability when it is central to a user journey or value stream. That team should understand the product outcome, the user need, the operational risk, and the agent’s behaviour in production.

A platform team may provide shared capabilities that make agentic product development safer and easier. That could include model access, deployment patterns, evaluation tooling, observability, guardrails, prompt and configuration management, tool registries, identity integration, and reusable orchestration patterns.

An enabling team may help product teams learn how to design, test, operate, and govern agentic systems. The aim should be to transfer capability rather than create a permanent queue of AI specialists.

A complicated-subsystem team may be appropriate where there is a genuinely difficult technical capability that requires deep expertise. Examples might include retrieval architecture, graph reasoning, evaluation frameworks, domain-specific models, multi-agent orchestration, or high-assurance control mechanisms.

The important principle is that agentic capability should not become an unowned subsystem.

If an agent is part of the product, it needs product ownership. If it is part of the platform, it needs a clear platform interface. If it is part of the delivery system, it needs to be understood as part of how teams work. If it crosses those boundaries, the boundaries need to be made explicit.

Team Topologies helps us design the organisation around the product. The Product System Lens helps us design the agentic capabilities inside the product.

Both are needed.

Towards a product architecture language for agentic AI

Agentic AI is not only a way to make delivery teams more effective. It is also a way to create new kinds of product capability.

Those two conversations overlap, but they should not be collapsed into one.

The Delivery System Lens is concerned with how agents help teams build, operate, and improve software. Team Topologies gives us a useful language for that lens because it focuses attention on team boundaries, cognitive load, platform capabilities, enabling support, and the flow of change.

The Product System Lens is concerned with how agents are embedded into products and services. This lens needs language for interaction modes, data boundaries, context, autonomy, execution, outputs, delegation, governance, and runtime choices.

The industry already has strong examples of agentic products. The knowledge is present in the tools being built and the systems being explored. What is less mature is the shared architecture language around those examples.

That language matters because it helps teams make better choices. It helps product people, engineers, designers, security specialists, platform teams, and organisational leaders talk about the same system with more precision.

Before we can build a useful taxonomy of product agents, we need to understand the dimensions that make one agent meaningfully different from another. Once we have those dimensions, archetypes begin to emerge. Once archetypes emerge, patterns, responsibilities, and operating models can follow.

This is still early language. It should be challenged, refined, and tested against real products.

But the distinction feels important:

The Delivery System Lens asks:

How do agents help teams deliver better software?

The Product System Lens asks:

How do we build better software products with agents inside them?

If we keep those lenses separate enough to reason clearly, but connected enough to design whole systems, we will have a better chance of building agentic products that are not only impressive, but useful, operable, and worth trusting.