<!-- Generated by scripts/i18n/translate.py from public/digital-workplace-agentico.md. Do not edit by hand: the next sync overwrites it. -->
# Agentic Digital Workplace — From Portal to Agent

> Markdown (GEO/AEO) version of <https://mauricio.issei.com.br/en/digital-workplace-agentico>. Author: **Mauricio Yokoyama Issei** · en-BR · Published: 2026-10-03 · Updated: 2026-10-03.

## In short

It's a corporate portal that stops **organize links** and passes the **resolve intentions**: the collaborator asks, the agent prepares, the person confirms and the process runs in the registration system. The agent is a link to a jail — **intent, agent, knowledge, tools, process, experience** — and depends on the foundations it crosses: if a link fails, it inherits the failure and does not correct it. Without them, he starts to perform actions with too broad credentials and no audit trail.

- **Five stages that accumulate** — from intranet to age platform; the model describes the cost of each stage jump, and maturity is assessed per journey, not by the entire portal.
- **Six layers and a crossband** — the study recommends that the rule should live in the field, that identity should spread and never replace, that the agent should be a channel and that the generative IU should compose approved components.
- **Autonomy goes up with evidence** — levels from 0 to 4 per class of action; the study recommends maintaining financial, legal or sensitive data at level 2 (implementation with confirmation) until there is evidence of safety.
- **Critical Path** — delegated identity and content governed with permissions are usually the slowest dependencies (study inference); therefore roadmap begins in phase 0.

## The thesis and its foundations

A corporate agent depends on the foundations it crosses: prioritized intent, governed knowledge, delegated identity, API contracts and explicit processes. The stage 5 chain — intent, agent, knowledge, tools, business process, dynamic experience — gives the agent the same weight as the other links: if another link fails, he inherits the failure and does not correct it.

## The five stages

1. Traditional Intranet (content, links, systems): “Where is it?” 2. Digital Workplace (content, services, personalization): “How do I ask?”. 3. Composite EXP (APIs, headless, journeys): “How do I resolve from end to end?” 4. AI-Enhanced Workplace: “What is the rule?” 5. Agentic Workplace: “Do this for me.” In the model proposed by the study, each stage accumulates the previous stages, and maturity is evaluated per day: an organization may be in stage 5 to consult holiday balance and number 2 to request access.

## Where to start

For a high-volume and low-risk pilot journey, with six passing criterion phases and seven parallel trails. Delegated identity (T2) and governed content (T3) are usually the critical path and begin in phase 0. The study recommends requiring evidence of safety and quality for each expansion of autonomy. The age readiness index, from 0 to 20, suggests what the journey supports today.

## Full content of the page

Agentic Digital Workplace

### From the portal that presents to the platform that solves

Those who conduct a large corporate portal hear two requests that contradict each other: “put an AI agent in front of everything” and “first fix the house”. This study shows, layer by layer, what needs to exist before an agent acts on behalf of a collaborator — and what happens when one of these layers is jumped.

A corporate agent is only as good as the foundations he goes through: prioritized intent, governed knowledge, delegated identity, API contracts and explicit processes. Without them, he's a chatbot with dangerous credentials. **[INFERENCE]**

Figure 1 · The chain of intent to experience **[RECOMMENDATION]**

1. **Intent** What does one want?
2. **Agent** Who acts?
3. **Knowledge** What's the rule?
4. **Tools** With what capacity?
5. **Business Process** With what owner and state?
6. **Dynamic experience** How does one see and confirm?

*Stage 5 maturity model formula. The agent is a link in the middle of the chain, with the same weight as the others: if any other link fails, he inherits the failure and cannot correct it.*

Where do you come in? (illustrative questions)

“They want an agent in front of everything. Where do I start?”

Phases with passing criteria and parallel trails; identity and content are the critical path.

Go to roadmap →

“Our RAG responds wrong or shows what it should not.”

The RAG is the last link of a chain; before it there is canonical source, metadata and permissions.

See the chain of knowledge →

“ With what identity will the agent act?”

Delegation, non-impersonation: subject, actor, minimum scope and authorization at the point of the data.

See identity and autonomy →

“ At what stage is our portal?”

Ten criteria, score from 0 to 20 per day, calculated in your browser.

Calculate readiness →

#### How to read this page

##### 2 minutes

Hero, stages of maturity and the block In short. You go out with the five-stage model and the thesis.

##### 12 minutes

Add architecture, flow, trust and roadmap.

##### About 45 minutes

The whole page, with the collectible deepenings and the thirty critical questions.

**Complete index**

1. Video summary
2. The problem: the collaborator as a human integrator
3. Five stages, from link to resolved intention
4. Six-layer reference architecture
5. A request from start to finish
6. The eight technical pillars
7. The chain of knowledge
8. Identity, autonomy and governance
9. The agent within the process
10. Twelve lenses, an architectural board
11. Trade-offs, anti-patterns and technological matrix
12. Operate an agent
13. Phases and trails
14. Agent readiness index
15. Thirty critical questions
16. Study trails by profile

Video summary **[RECOMMENDATION]**

#### Before technical layers: video study

The video presents the ladder of evolution of the portal and the governance foundations that precede the agent. If you already know the model, skip to the problem: nothing that comes after depends on watching.

**==References== How to Evolve from the Corporate Portal to the AI Agent.** The video deals with the architecture of knowledge and the danger of hallucination. Reinforces that maximum autonomy for sensitive actions remains in the **level 2**, which requires the formal review by HITL (identity, autonomy and governance). *

Skip the video and continue reading ↓

**Textual video summary**

- **Knowledge:** the agent only responds well about what the architecture of knowledge governs; without canonical source, validity and permissions, the fluent response may be wrong (hallucination). See the chain of knowledge.
- **Delegated identity:** the agent acts with the identity of the collaborator in minimum scope, not in his place. See identity and governance.
- **MCP:** is the bridge between the abstract intention of the request and the actual execution in the backend systems, by the integration layer. See architecture in six layers.
- **Autonomy:** sensitive actions are at level 2, at most, with human confirmation (HITL) before effect.

Support text, not an integral transcript of the video.

The Problem **[INFERENCE]**

#### The collaborator as a human integrator

In a large corporate portal, the collaborator deals with dozens of systems: HR, point, benefits, accesses, calls, learning. The traditional portal organizes **links** for these systems. The person who integrates is the person: he needs to know where everything is, what the current rule is and in what state the request itself is.

The question that organizes this study is another: **what needs to exist so that “do this for me” is safe, auditable and useful — and in what order to build?**

**[INFERENCE]**

##### 1. The work is digital and fragmented

Each domain has its own experience, language and queue. The sum of these maps is what the collaborator carries on his head.

**[INFERENCE]**

##### 2. Expectation Changed

Asking in natural language and receiving a source response has become a common expectation in consumer tools and tends to be taken to work.

**[FATO]** **[INFERENCE]**

##### 3. Agents have become technically viable

Open protocols (MCP, A2A, AG-UI) and models with tool calling make it possible to act, not only to respond. The existence of protocols is a fact; the viability on a corporate scale is inference.

**What this study is not**

- It is not the description of a specific portal: the subject is always “a large corporate portal”.
- It is not supplier recommendation: the technological matrix compares, does not elect.
- It does not propose a unique ideal architecture: there are explicit trade-offs and decisions that depend on the context.
- There are no dates: the roadmap has phases and criteria of passage, because the duration depends on the current state, which only the discovery reveals.

**How to read stamps**

Every block derived from the study carries a stamp. The label is text; the color is not the only carrier.

****[FATO]****

Verifiable in primary source (specification, RFC, official documentation, law).

****[INFERENCE]****

Conclusion derived from facts, with explicit reasoning.

****[HYPOTHESIS]****

Plausible assumption, not yet verified.

****[RECOMMENDATION]****

Architecture position proposed by the study. When a block mixes labels, it's worth the weakest.

**Symbols and terms used on this page**

**EXP (Employee Experience Platform)**

Layer that organizes employee services and journeys on registration systems.

**SoR (registration system)**

Where is the official data and business rule: sheet, point, benefits, service.

**ECM and CSP**

Corporate Content Management (*enterprise content management*) and content service platform (*content services platform*): the governed repository and its version exposed as a service.

**Headless**

Structured content in fields and delivered by API to any channel without docked screen.

**RAG (*retrieval-augmented generation*)**

Answer generated by a model from excerpts from documents recovered by search.

**Groundedness**

The answer is based on the cited sources.

**ACL, IdP and SSO**

List of document permissions; identity provider; unique login.

**AG-UI, MCP, A2A, A2UI**

Open protocols: agent interaction ↔ application; agent ↔ tools; agent ↔ agent; and a declarative interface format generated.

**HITL (*human-in-the-loop*)**

Confirmation or formal human decision before action in effect.

**BFF (*backend for frontend*)**

Layer that adapts APIs to the channel that consumes them — here, the agent channel.

**ESB, CDC and outbox**

Central integration bus; capture of changes in the bank of a legacy; pattern that saves the state and event in the same transaction.

**SLI, SLO and error budget**

Indicator, objective on the indicator and how much of the goal can be missed before freezing changes.

**DEX (*digital employee experience*) and ILM**

Digital experience of the collaborator; management of the information life cycle (retention and disposal).

**LGPD**

General Data Protection Act (Law No 13.709/2018).

Maturity **[RECOMMENDATION]**

#### Five stages, from link to resolved intention

The model describes the evolution of a five-stage portal. Each stage **accumulate** the previous: a `Agentic Workplace` without the foundations of stages 2 to 4 is a chatbot with dangerous credentials **[INFERENCE]**. The model is a proposal for discussion; the positioning of a concrete portal is only supported by criteria and evidence.

1. # # 1. Traditional Intranet
  Content + Links + Systems
  **The collaborator asks**
  “Where is it?”
  **The platform responds**
  “Here’s the link”
2. ##2. Digital Workplace
  Content + Services + Customization
  **The collaborator asks**
  “as I ask?”
  **The platform responds**
  “Here’s the service for you”
3. ##3. Componsible EXP
  APIs + Headless + Days + Micro-frontends
  **The collaborator asks**
  “How do I resolve from end to end?”
  **The platform responds**
  “Follow this journey without changing the system”
4. ##4.
  Search + RAG + Copilots + Automation
  **The collaborator asks**
  “What’s the rule?”
  **The platform responds**
  “this is the answer, with source”
5. # # 5. `Agentic Workplace`
  Intent → Agent → Knowledge → Tools → Process → Dynamic experience
  **The collaborator asks**
  “Do this for me”
  **The platform responds**
  “I understood, prepared, confirmed, is in progress”

*Figure 2 · Mature ladder. With JavaScript, the button of each step highlights the corresponding column of the matrix below; without JavaScript, ladder and matrix appear whole.*

##### Comparative matrix by size

**Dimensions × stages (E1 to E5). Each column accumulates the capabilities of the above.**

| Size | E1 · Intranet | E2 · Digital Workplace | E3 · Composite EXP | E4 · AI-Enhanced | E5 · `Agentic` |
| --- | --- | --- | --- | --- | --- |
| Value unit | page | service | journey | response | intention solved |
| Integration | links | point to point | contracts | contracts + index | contracts + tools + delegation |
| Content | pages | pages + catalog | headless | governed and indexed with ACL | governed, indexed and used for action |
| Identity | login | SSO | SSO + profile | SSO + Index permissions | subject delegation + actor |
| Case | outside the portal | forms | workflows | workflows with LLM steps | agent as process interface |
| UX | menus | catalog | journeys | natural language | intention + adaptive IU |
| Operation | availability | availability | SLOs per capacity | + quality of responses | + Agent Traces, Cost, Quality Error Budget |
| Governance | editorial | catalog | contracts | AI and data | autonomy and audit |

##### Jumping stages has cost **[INFERENCE]**

##### E2 → E4, without E3

The RAG works for questions, but there are no APIs to act on: the “agent” only responds.

##### E2 → E5, without E3 and E4

Agent with improvised integrations, broad credentials and ungoverned knowledge. High risk of incident.

##### E3 → E5, without E4

Well integrated actions, but untrustworthy knowledge responses without indexed permissions.

It is possible to go in parallel by trails — start content governance of E4 while building the E3 APIs — but the study does not recommend operating the E5 without previous capabilities **within the scope of qualified intentions**. That is why maturity is assessed per day, not by the entire portal: an organization can be in stage 5 to “see holiday balance” and stage 2 to “request access” **[RECOMMENDATION]**.

**Criteria to be considered at each stage**

To be in an internship, the organization meets the **all** His criteria. Stage 1 has no entry criteria.

##### Stage 2

- SSO on all portal services.
- Service catalogue with owner per service.
- At least three domains with transactional self-service.

##### Stage 3

- Ability of priority days accessible by API with versioned contract.
- Experience content delivered by API to more than one channel.
- At least one cross-domain journey with owner and workflow.
- Design system used by all experience teams.

##### Stage 4

- Hybrid search with permissions applied in the index.
- Regulatory content with validity and owner in 100% of the indexed scope.
- Evaluation set with monitored recovery metrics.
- AI policy and inventory of use cases.

##### Stage 5

- Token delegate (subject + actor) on all tools.
- Data point authorization for all actions.
- Formal HITL for effective actions.
- Generating UI restricted to catalog.
- Auditable execution log.
- Quality SLOs with bug error.

**What each internship requires: capabilities, risks and organizational change**

**Capabilities, risks and organization by internship.**

| Stage | Capabilities | Main risks | Organisation |
| --- | --- | --- | --- |
| 1 · Intranet | intranet CMS, link directory, news, simple search | outdated content; collaborator as “human integration” | internal communication portal owner |
| 2 · Digital Workplace | SSO, service catalogue, audiences, self-service in some domains, mobile app, call opening | catalog that is just a list of links; superficial customization | employee digital product begins to exist; domains provide services |
| 3 · Composite EXP | Domain APIs with contract; headless content; cross-domain journeys; multichannel system design; workflow for long processes | microservices and micro-frontends without need; BFF turning monolith | domains such as capabilities owners; platform team; journey owner |
| 4 · AI-Enhanced | hybrid search with permissions; RAG with citations; copilots in specific tasks; workflows with LLM steps | RAG on ungoverned content; oversharing leakage; hallucination | owners of content with curated time; AI committee; AI platform team |
| 5 · `Agentic` | agent with reading and writing tools; delegated identity; Formal HITL; regulated generative UI; interaction protocol; execution record | excess agency; agent-ESB; rules in the prompt; quiet incidents of quality; instability of protocols | tool and permission forum; process owners receiving agent feedback; Quality SRE |

“Micro-frontends” in stage 3 formula indicates modularity of experience, not the obligation to adopt them in runtime.

Reference architecture **[RECOMMENDATION]**

#### Six layers and a crossband

The model below is neither a definitive architecture nor the description of a portal: it is a reference for positioning decisions, finding dependencies and talking between disciplines. Each layer has a responsibility and, as important as, what **no** It's her responsibility. The bottom layers (integration, knowledge, identity) are the prerequisite of the top layers (agent, generative UI).

Collaborator — intent, navigation, confirmation

**** Experience Layer** web, mobile, collaboration channels, notifications, generative UI, client AG-UI**

**Experience Layer**

| Is responsible for | You are not responsible for |
| --- | --- |
| render approved components on any channel | decide business rules |
| capture intent, confirmations and editions | call registration systems directly |
| accessibility and visual consistency | store state of process |
| maintain the AG-UI connection and apply status (snapshots, deltas) | authorize actions (just reflects what the backend allows) |

AG-UI (events, state, interruptions)

****Agent / Interaction Layer** Agent runtime, versioned instructions, task status, guardrails, HITL, MCP and A2A customers**

**Agent / Interaction Layer**

| Is responsible for | You are not responsible for |
| --- | --- |
| interpret intention and plan | be the source of the truth of any given |
| choose allowed catalog tools | contain eligibility rules |
| conduct confirmations and interruptions | maintain long-term processes |
| explain results with sources | decide permissions |
| record execution (trace) | integrate point-to-point registration systems |

service and day consultation · tools (MCP)

**** Employee Experience Platform (EXP)** catalogue of services, journeys, profile and context, customization, status of requests**

**Employee Experience Platform**

| Is responsible for | You are not responsible for |
| --- | --- |
| catalogue of services and their display rules | execute domain business rule |
| definition of journeys, including cross-domain | interpret natural language |
| profile and context of the collaborator, with legal basis | be the normative content repository |
| aggregated status of requests and notifications |  |

**[INFERENCE]** EXP allows the traditional agent and navigation to offer the same services, with the same display rules. Without it, the agent creates a parallel catalogue.

****Knowledge** canonical content, taxonomy, hybrid index with ACL, retrieval, RAG**

**Knowledge**

| Is responsible for | You are not responsible for |
| --- | --- |
| canonical content with metadata, validity, owner and permissions | generate answers |
| Hybrid index with synchronized ACLs | decide, in the generation, what the user can see |
| retrieval with filters and reranking; high value entity graph |  |

****Integration** MCP servers by domain, gateway, agent BFF, APIs, workflow engine, events**

**Integration**

| Is responsible for | You are not responsible for |
| --- | --- |
| expose domain capabilities by contract | contain business rules |
| BFF adapted to agent channel; durable processes (workflow) | interpret intentions |
| distribute reading events and projections; resilience (timeouts, circuit breakers, idempotence) |  |

Contract APIs

****Corporate Systems (SoR)** HR and sheet, point, benefits, ITSM, IAM, service, legacies**

Source of truth and rule. Change slowly; architecture must **protect them.** the load and call patterns introduced by agents (rate limit, cache, reading projections).

##### Transversal (all layers)

- IAM and delegation
- Policy engine
- Security
- LGPD
- IA Governance
- Audit and lineage
- Observability (tracks, metrics, evaluations)
- SRE
- DEX

*Figure 3 · Reference layers. Each track opens the table of responsibilities; the order of the document is the order of reading, from top to bottom.*

##### Nine principles that cross the layers **[RECOMMENDATION]**

1. **The rule lives in the domain.** No layer above registration systems and domain services decides eligibility.
2. **Identity spreads, never replaces.** Every call carries who asked and who is acting.
3. **The agent is a channel.** It uses the same EXP, the same APIs and the same policies as the other channels.
4. **Generating IU is the composition of approved components.**
5. **Process status is durable and external to the agent.**
6. **Knowledge is governed in origin.** The index reflects; it does not correct.
7. **Every execution is reconstructable:** Who, what, based on what, with what authorization.
8. **Gracious degradation.** If the agent fails, the traditional navigation continues.
9. **Protocols behind adapters.** AG-UI, MCP and A2A are encapsulated to absorb specification changes.

**Open decisions per layer**

**Each decision has legitimate alternatives; the choice depends on the inventory of each organization.**

| Layer | Decision | Alternatives |
| --- | --- | --- |
| Experience | SaaS platform own shell or extension | modular monolith, micro-frontends, server or border composition |
| Experience | Generative UI specification | A2UI, MCP Apps, Open-JSON-UI, own schema |
| Agent | platform agent or independent | see paradox in Decisions |
| Agent | an agent or multi-agent; where the model runs | single agent with filtered catalog; managed, private or local cloud |
| EXP | build, buy or use the existing suite | depends on the inventory |
| Knowledge | search engine | Elasticsearch, OpenSearch, managed service |
| Integration | Direct MCP to domains or via BFF | servers Fine MCP calling BFF and APIs |
| Transversal | model authorisation | RBAC, ABAC, ReBAC or combination |

Flow tip to tip **[RECOMMENDATION]**

#### A request from start to finish: agent, AG-UI, tools and process

illustrative scenario: a collaborator writes *“My daughter was born yesterday. I need to include her in health care.”* The request is a good test because it brings together intention with emotional burden, sensitive personal data, eligibility rule with deadline, document collection, action with effect, asynchronous process with possible human analysis and a longer journey (license, sheet) that can be suggested.

The sequence below is **illustrative**: is not a real execution or the description of an existing system. Event names follow the AG-UI 1.0 specification.

1. RunAgentInput Collaborator → Interface → Agent The request comes out with the collaborator's token. Runtime doesn't use this token to call systems: trade it, with each tool, for a delegate token.
2. `RUN_STARTED` Agent → Interface Start of execution and creation of trace with correlation ID.
3. `ACTIVITY_SNAPSHOT` Agent → Interface Transparent progress; the screen reader receives a moderate ad.
4. Context of EXP and knowledge Agent → Tools Only the current and allowed content, with ID, version and validity, enters the context.
5. `TOOL_CALL_START' · eligibility Agent → Tools (token delegate: subject + actor) The staff member receives “eligible, deadline, required documents”; does not decide eligibility.
6. `TOOL_CALL_START` · render_dependant_form Agent → Interface Frontend tool: Who defines the catalog is the application, not the agent.
7. `STATE_DELTA` Agent ↔ Atomic Patch JSON Interface: applies whole or is rejected, with snapshot resynchronization. The attachment goes to a document repository; the agent receives only the reference.
8. `RUN_FINISHED` · interrupção `confirmation_action Agent → Interface “A interrupted execution is a finished execution”: the answer comes in a new execution.
9. Confirm Collaborator → Interface → Agent Explicit confirmation, with readable summary and possibility to edit without restarting.
10. `TOOL_CALL_START` · start include Agent → Tools → Workflow Repeat call does not duplicate inclusion; process status lives in workflow engine.
11. `TEXT_MESSAGE_*` · `RUN FINISHED` Agent → Interface Asynchronous conclusion: days later, the workflow publishes the event and the EXP notifies. If there is an exception, the human task is born with structured context.

All steps are visible. With JavaScript, you can browse them one by one.

*Figure 4 · Illustrative sequence **[RECOMMENDATION]**. Purple marks human decision; amber action with effect. The event names are **[FATO]** according to the specification AG-UI 1.0.*

##### What AG-UI is — and what is not

**[FATO]** AG-UI (Agent User Interaction Protocol) is a protocol to connect user-oriented applications to agents by event flows. Each application initiates an execution (*run*) that returns events to the application. He lives with two other protocols: MCP connects agent and tools; A2A connects agents with each other; AG-UI connects the agent to the user.

So the answer to the question “AG-UI is UI protocol, integration or interaction?” is: **of interaction**. Him **no** is a generic UI specification (this is A2UI, MCP Apps, Open-JSON-UI), is not integration with corporate systems, is not authorisation mechanism and is not agent framework. It carries proposals for action; it authorizes tools and systems.

**The eight families of AG-UI events**

**Specification 1.0. **[FATO]** as to events; the column of use is **[INFERENCE]**.**

| Family | Events | Use in a Digital Workplace |
| --- | --- | --- |
| Runs and steps | `RUN_STARTED`, `RUN_FINISHED`, `RUN_ERROR`, `STEP_STARTED`, `STEP FINISHED` | life cycle of a request; basis for latency metrics |
| Text messages | `TEXT_MESSAGE_*` | conversational response on streaming |
| Tool calls | `TOOL_CALL_*` | proposed action; arguments come in fragments |
| Reasoning | `REASONING_*` | visibility of reasoning, with encrypted artifacts |
| Status | ‘STATE_SNAPSHOT`, `STATE_DELTA`, `MESSAGS SNAPSHOT` | shared status, such as draft of a request |
| Activity | ‘ACTIVITY_SNAPSHOT`, `ACTIVITY_DELTA` | structured progress outside transcription (“checking eligibility...”) |
| Subagents | 'SUBAGENT_STARTED`, `SUBAGENT_FINISHED`, `SUBAGENT ERROR` | output assignment to subagents |
| Passthrough | `RAW`, `CUSTOM` | escape for proprietary events; in excess, loses interoperability |

**State, interruptions and transport**

- **[FATO]** **Snapshot** replaces the whole state ("not a merge"). **Delta** applies JSON Patch (RFC 6902) operations atomicly. If a patch fails, the consumer rejects the partial result and the producer must resynchronize with a snapshot.
- **[FATO]** An execution that needs external input ends with `RUN_FINISHED` loading a break (id, motive, readable message, response schema). The producer shall not report it as success or perform the action if the interruption is not covered by the resumption.
- **[INFERENCE]** Thus, human approval ceases to be an “if” in the agent code and becomes a protocol event, with schema of response, expiration and explicit rule of non-execution — which facilitates auditing.
- **[FATO]** The required transport is HTTP with Server-Sent Events; Protobuf is optional; WebSocket is not binding default, but is allowed. Any transport shall deliver the events of an execution in an orderly and complete manner.
- **[INFERENCE]** Proxies and CDNs cannot buffer SSE; the stream needs valid token throughout the run; on unstable mobile networks, snapshots resynchronize the state.

**What changes if... (five variations of the scenario)**

**Differences **[RECOMMENDATION]****

| Difference | Impact |
| --- | --- |
| The collaborator is in a collaboration tool | the same agent and status; the component renders as card; the attachment may require link to the app |
| The benefits system is out of the air | circuit breaker open; agent explains, saves draft and offers reminder or call |
| Politics changed yesterday. | the index reflects the new version per life cycle event; the responses cite the new version of the index. |
| Ask for someone else's daughter | the tool solves “dependent” by the identity of the requester and does not accept arbitrary text IDs |
| An indexed document contains malicious instruction | the recovered content is treated as given; guardrails and the absence of dangerous tools limit the impact of |

In the vertical of agents, the same drawing — agent cycle, fail-closed, HITL — is detailed in [AI Agent Engineering](https://mauricio.issei.com.br/en/engenharia-agentes-ia).

Technical pillars

#### The eight pillars under architecture

Each pillar answers a question the agent alone does not answer. The cards summarize the main finding; the deepening of each is collected. The same criterion applies to all: **What exists, what is missing and what is not his responsibility**.

**[INFERENCE]**

##### 1 · EXP and Digital Workplace

The intranet **inform and forward**; a EXP **executes and accompanies**. It organizes services and journeys on registration systems, with identity, context and delivery in various channels.

**Modern Intranet × EXP, composable and MACH**

**Operational differences**

| Size | Modern Intranet | EXP |
| --- | --- | --- |
| Unit | page and section | journey and service |
| Systems | link or embed | API; action within the experience |
| Background | hearing (area, location) | profile, moment of life, state of requests |
| Channel | web, mainly | web, mobile, collaboration, notifications |
| Success | visits, reach | resolution, time to resolution, effort |
| Owner | internal communication | product, with domains such as service providers |

An EXP does not need to be componsible: for agents, the real requirement is that capabilities are exposed **by contract**. MACH is a possible strategy, not a requirement; MACH Alliance is an association of suppliers, and its material is market positioning **[INFERENCE]**. API-first and headless are for agents; microservices only where there is organizational border.

**[RECOMMENDATION]**

##### 2 · Modular front-end

Micro-frontends solve a problem **organization** (deploy independent teams), not technical. Without the measured need, a modular monolith usually serves the same purpose **[INFERENCE]**.

**When adopting micro-frontends in runtime**

Only if the three conditions are true:

- there are at least three teams delivering interfaces in the same shell, with different rhythms;
- the cost of coordination of releases is a measured, missed bottleneck;
- there is a platform (time and tools) to take care of shell, shared dependencies and integration tests.

The options, from the lowest to the highest cost: modular monolith; micro-frontends in build time; in runtime (Module Federation); orchestrator as single-spa (for gradual migration); composition on server or edge; iframes (total isolation, with UX and bad accessibility). The design system is the common platform; the client AG-UI lives in the shell. Streaming by SSE requires that proxies and CDNs do not buffer the answer.

**[FATO]** **[RECOMMENDATION]**

##### 3 · Generative IU governed

The agent **composes** the screen from a catalogue of approved components; does not generate free HTML. The Component Registry is the contract between the agent and the design system.

**Specifications, registration and implementing rules**

- **A2UI** (Google): Declarative format, “not executable code”; the client keeps the catalog and the agent only asks for components of it. Version 0.8 in December 2025.
- **MCP Apps**: pre-declared `ui://` resources, rendered in isolated iframes; proposal November 2025.
- **Open-JSON-UI**: standardization of declarative schema cited in the AG-UI documentation. Or a proper schema about the design system.

The current status of each specification may have changed since the date of the source.

A record entry describes: when to use and when not to use (for agent), JSON Schema of props, issued shares, side effect, required context, accessibility audit and owner. Rules: only registered components are instantiated; props are validated before rendering; collateral-effect components run nothing on the client — the action passes through the backend, which reapplies the authorization; text from the model is given unreliable.

**[FATO]** **[INFERENCE]**

##### 4 · Content governed: from ECM to headless

The content must have usable metadata per machine: duration, owner, permission and applicability. Without it, search and RAG inherit the problem and cannot correct it.

**Three generations and what the agent requires of the content**

**ECM** keeps records with control, version and retention. **CSP** Gartner formalized the exchange of the term in 2017. **Headless** structure the experience content in fields and API delivery to any channel. The three coexist: records with retention stay in ECM/CSP; communiqués, FAQs and guides benefit from the headless model. The mistake is trying to solve everything with one.

**What the agent requires of the content **[INFERENCE]****

| Request of the agent | Content capacity |
| --- | --- |
| cite the current version | duration (start and end) and status |
| do not reveal restricted content | explicit and exportable permissions to the index |
| answer to the right audience | applicability metadata (load, area, region, link) |
| understand synonyms | controlled taxonomy |
| knowing who corrects a wrong answer | owner and revision cycle |
| recover the right snippet | structured content in sections, with titles and hierarchy |
| delete when the law commands | ILM and retention propagated to index and logs |

**[RECOMMENDATION]**

##### 5 · Integration: gateway, BFF, events and workflows

The agent needs to **contracts**Not microservices. The BFF shapes the capabilities for the agent channel; the workflow engine saves the process status; none of them contain business rule.

**API, event or workflow? And the role of BFF**

**When to use each**

| Criteria | Synchronous API | Events | Workflow engine |
| --- | --- | --- | --- |
| Interaction | immediate question and answer | fact already occurred | steps over time |
| Consumers | one | several | a process |
| Duration | ms to seconds | continuous | minutes to months |
| Wrong usage sign | timeouts in long operations | events used as request-response | engine for a simple call |

The agent's BFF reduces payload and noise (tokens cost and confuse), aggregates frequent queries, normalizes errors in explicable messages, imposes pagination and applies the agent channel specific policy. Legacy without events can use CDC; transactional outbox avoids “state changed, event lost”. The agent **start** the workflow with idempotence key, **consultation** the state and **responds** human signs — never keeps the state in its own memory.

**[FATO]** **[RECOMMENDATION]**

##### 6 · Search, RAG and graphs of knowledge

Lexical and semantic search have different blind spots; the hybrid combination with **index permission filter** It's the base. The RAG only comes in later, and evaluation comes before technology.

**Techniques, classic RAG × RAG with agent and evaluation**

**Strong and blind points**

| Technique | Strong in | Weak in |
| --- | --- | --- |
| Lexical (BM25) | acronyms, normative codes, names, numbers | synonyms and paraphrases |
| Dense semantics | questions in natural language | rare terms, denial, exact numbers |
| Hybrid | robustness | calibration and evaluation |
| Reranking | accuracy in the first results | latency and cost |
| Knowledge graph | relational and global questions | construction and maintenance |

The merging of lists by RRF (*Reciprocal Rank Fusion*) combines results by post without normalizing scores. The RAG was formalized by Lewis et al. (2020). O **Agent RAG** wins in composite questions (political + personal data) and loses in predictability, latency and cost; for simple policy questions, the classic RAG tends to be more appropriate. Models make worse use of information in the middle of long contexts (Liu et al., 2023): fewer excerpts, more relevant. Assessment by layer: recovery (recall@k, nDCG), permission (empty should be zero), grounding, correction and utility.

**[INFERENCE]**

##### 7 · Agents, tool calling, MCP and A2A

The MCP is the standardized interface between the agent and the tool catalog; **no** solves business rule, integration with systems or long processes. Start with an entry agent and a catalogue filtered by intent.

**Anatomy, MCP, A2A, guardrails and tests**

- **[FATO]** MCP servers in HTTP transport are resource servers OAuth: validate the token audience and **don't go over** token received to APIs. The review 2026-07-28 removed sessions and the startup handshake and documented the trace context spread — the specification still changes incompatiblely.
- **[RECOMMENDATION]** Servers Fine MCP, per domain, maintained by the domain team and calling BFF and APIs; not a central “corporate MCP server”.
- **[FATO]** A2A is an open standard of communication between agents, under the Linux Foundation, with technical committee formed by large cloud providers, ERP and service. Use multi-agent when there is owner, policy or supplier border — not as “prompt organisation”.
- **Guardrails** at each point: injection into the input; recovered content treated as unreliable data; filtered tool catalog; arguments validated by schema and solved by identity, not by text; foreign policy decides action; masking on exit; limit of steps, time and cost.
- **Layer tests:** tool (contract, idempotence, authorization), tool selection, trajectory, result with simulated systems, safety (red teaming), regression in IC and sample evaluation in production. Instructions, catalog and model version are versioned artifacts.

**[FATO]**

##### 8 · AG-UI: interaction protocol

It standardizes the conversation in real time between the agent and the application: what the agent is doing, what he proposes, what they both know and when he needs the human. It's not UI protocol, integration protocol, or authorization protocol.

**Dependencies, risks and maturity**

- **Dependencies:** compatible agent runtime; system design with registrable components such as frontend tools; long-term streaming infrastructure; well-defined state model.
- **Risks:** specification instability (internal adaptor and contract tests); leakage by reasoning events; state as injection channel (validate against schema); frontend tools with effect (always via backend); excess of `CUSTOM` events.
- **[INFERENCE]** Emerging maturity, in consolidation: suitable for pilots with encapsulation; premature as non-encapsulated long-term dependence.

Detail in Flow point by point.

Knowledge **[INFERENCE]**

#### From repository to agent: the chain of knowledge

Every link in the chain **inherits the quality of the previous and cannot correct it**. The RAG does not correct a wrong permission in the ECM; the agent does not correct an absent term in the CMS. So the RAG is the last link, not the first: before it there is canonical source, metadata, permissions and index.

1. **1 · ECM**Keep records with control, version and retention. “What is the official document and how long should I keep it?”
2. **Gate A · canonical source, owner and classification**
  Each type of content has a defined canonical source, an owner responsible for the correction and a classification of information (public, internal, confidential, restricted) with rule of use by AI.
3. **2 · CSP**It exposes this content as services for various applications. “How do other applications access governed content?”
4. **3 · Headless**Structures field experience content and API delivery. “How do I reuse the same content on web, app, collaboration and agent?”
5. **Gate B · duration and permission in 100% of scope**
  Status and duration (vigid, revoked, beginning and end) in all normative content; explicit and exportable permissions, synchronized with the index.
6. **4 · Search**Find the relevant passage respecting permission and context. “Where is the answer to this person?”
7. **Gate C · evaluation set and leak test**
  Real questions with reference answers, measured recall and leak test with low privilege identities after each index load.
8. **5 · RAG**It generates an answer based on the excerpts found. “How to respond in natural language without inventing?”
9. **6 · Agent**Use knowledge and tools to resolve intent. “What to do with this information?”

*Figure 5 · Chain of knowledge with ready gates. The gates are the criterion of passage between the stations; each opens the corresponding checklist.*

**RAG readiness checklist **[RECOMMENDATION]****

##### Blockers (6)

Without it, do not implement RAG in production.

- Canon source defined for each type of content.
- Explicit and exportable permissions, synchronized with the index.
- Status and validity in all normative content.
- Owner of each content, with responsibility for correction.
- Classification of information, with rule of use by AI.
- Evaluation set with real questions and reference answers.

##### Strongly recommended (5)

- Controlled taxonomy and synonym thesaurus.
- Applicability metadata (company, link, position, region).
- Structure of sections in the normative.
- Life cycle events (published, revoked, modified, discarded permission).
- Deduplication between repositories.

##### Desirable (3)

- Graph of high-value entities.
- Summaries cured for long documents.
- Glossary of acronyms.

**Pipeline intake and permission-aware retrieval**

**Eight steps, each with its quality control **[RECOMMENDATION]****

| Step | Function | Quality control |
| --- | --- | --- |
| Capture | receive publication and change events | no content enters without traceable event |
| Extraction | text, structure, tables; OCR when needed | Registered OCR trust |
| Standardisation | cleanliness, language, title standardization | — |
| Segmentation | Chunks by structure, with title and section path | verified size and consistency |
| Enrichment | inherited metadata, entities, synonyms | mandatory metadata present |
| Vectorization | model versioned embeddings | registered model version |
| Index | hybrid index with ACLs and metadata | leak test after each load |
| Removal | withdrawal and discard propagated | Propagating SLO |

**Permission-aware retrieval** in five steps: permissions as metadata of each chunk, inherited from the origin; prefilter in the index, with the identity solved by the idP and *never after* of the model see the content; event-oriented synchronization, with SLO; continuous leak tests with low privilege identities; overshare review before indexing.

**How an agent uses knowledge — and a rule that does not bend**

**Three uses, three requirements**

| Usage | Example | Request |
| --- | --- | --- |
| Reply | “What is the rule of teleworking?” | RAG with citation and duration |
| Decide what to do | “my daughter was born” triggers the day of birth | catalogue of services and journeys (EXP), not only documents |
| Grounding an action | explain why inclusion has a deadline | the rule comes from the domain (API); the document only explains |

**[RECOMMENDATION]** Never use the text of a recovered document as a rule source to execute an action: **the document explains; the API decides**. Transactional data goes by tool; structured content, by Content API; normative content, by RAG with filters; relationships, by graph or domain API; tacit knowledge *no use* — it is explained first or referred to a person.

**Suggested implementation sequence (seven steps)**

1. Choose **a domain** high-volume questions (e.g. people's policies).
2. Do inventory and define canonical sources, owners and durations.
3. Build the evaluation set from the real logs.
4. Implement hybrid search with permissions and measure recovery.
5. Only then add RAG, with citations and assessment of groundedness.
6. Then connect to the agent and the tools.
7. Expand domain to domain.

Knowledge as a governed infrastructure, not as a passive repository, is the theme of [Knowledge OS Enterprise](https://mauricio.issei.com.br/en/knowledge-os-presentation).

Identity, autonomy and governance **[RECOMMENDATION]**

#### In the name of who the agent acts — and how far he goes alone

In a traditional portal there are two identities: the user and the system. With an agent there are at least four: **user** (subject), **agent** (actor), **rantime** where it spins and every **resource** Accessed. If they mix, the organization loses the smallest privilege and the ability to assign responsibility.

##### Shortcut 1 · service account with wide access

Simple and works with legacies. But every action seems done “by the system”, the agent reaches data from any collaborator and the principle of the smallest privilege ceases to apply.

##### Shortcut 2 · pass user token

The registration system already understands the token. But he does not distinguish the user from the agent, the audience may be wrong, and the MCP expressly prohibits the *token passthrough*.

##### Delegation, never impose **[FATO]**

RFC 8693 distinguishes both cases. In impersonation, A “is indistinguishable from B”. In the delegation, A maintains its own identity and is explicit that acts as representing B: the claim `act` identifies the actor, and who consumes the token considers the subject and the actor when applying the policy. A delegate token, illustrative:

```
{
  "iss": "https://idp.exemplo.corp",
  "sub": "colaborador:123456",
  "aud": "https://bff-agente.exemplo.corp",
  "scope": "beneficios.dependentes.read",
  "act": { "sub": "agente:assistente-pessoas:v3" },
  "exp": 1791000000
}
```

Fictitious values. The “whose” comes from the token, never from parameters generated by the model: “my balance” turns the token `sub`, not an ID informed in the text.

##### Autonomy ladder, from 0 to 4 **[RECOMMENDATION]**

**Autonomy is by class of action and rises with evidence, not by decree.**

| Level | Example | Control | Ceiling for sensitive actions |
| --- | --- | --- | --- |
| 0 Informs | responds with sources | none | inside the ceiling |
| 1 Suggests | proposes the action and prepares the form | user executes | inside the ceiling |
| 2 Run with confirmation | summarizes and asks “confirm” | HITL interruption | inside the ceiling (limit) |
| Recommended ceiling for sensitive actions: financial, legal or sensitive data in regulated sector remain at level 2, at most, until there is accumulated evidence of security. |  |  |  |
| 3 Executes and notifies | low risk reverse actions | undo available; audit | above the ceiling |
| 4 Execute without human | very low risk routines | explicit policy; monitoring | above the ceiling |

*Figure 6 · The dashed line marks the ceiling; the last column repeats the text limit for those who do not distinguish color.*

##### The six questions and their architectural answers

##### Who authorized the agent?

Organizational level: tool and permission forum, with registration of those who approved, for which case of use and with which risk. User level: authenticate and, for high impact actions, confirm by registered interruption.

##### Who are you acting for?

The user, by delegation (subject + actor), with specific audience by tool and minimum scope.

##### What permissions do you have?

The intersection between what the user can, what the agent is allowed to do and what the current task requires. Never more than the user, and usually less.

##### What data can you consult?

Knowledge: only what the user sees, filtered in the index. Transactional: only by tools that solve the “whom” by the token. Sensitive: classified tools and registered access.

##### What actions can you perform?

It depends on the class of the action (table below): of own reading, allowed with delegated token, to actions that are not even exposed to the channel agent.

##### How to prove it later?

With an immutable execution log per task, correlated to the log of the registration systems.

**Action classes and suggested rule**

**Rule by action class **[RECOMMENDATION]****

| Class | Example | Rule |
| --- | --- | --- |
| Own data reading | hour balance | allowed with delegate token |
| Reversible writing | request draft | permitted; notify |
| Written with effect | subject vacation, include dependent | explicit confirmation (interruption) |
| Financial, legal or access effect | change bank account, grant access | confirmation + strong reset; possibly third-party approval |
| In the name of another person | manager approving | only with verified role and specific policy |
| Forbidden on Agent Channel | withdrawal, wage change | not displayed as tool |

**Authorization: RBAC, ABAC, ReBAC, policy as code and Zero Trust**

Agents push the authorization of pure RBAC for combinations with ABAC and ReBAC, because the decision depends on **actor**, **action** (risk class) and **context** (Was there confirmation? What channel?) **[INFERENCE]**.

- **RBAC:** roles; good for stable permissions per function; suffers from paper explosion.
- **ABAC:** attributes of subject, resource, action and environment; good for contextual rules; complex auditing policies.
- **ReBAC:** relationships (“is manager”); requires consistent graph; the reference is Zanzibar’s paper.
- **Policy as a code** (OPA, Cedar): consistency between layers and policy tests; requires governance of policies.

**[RECOMMENDATION]** The point of application (PEP) **mandatory** is the closest to data — domain API or registration system. The former reduce the surface, but never replace the latter. OWASP recommends applying the authorization to downstream systems, and not depending on the decision of the LLM **[FATO]**. Zero Trust (NIST SP 800-207) turns: *tool call* with token, audience and scope of its own; no confidence for being “within the network”; short tokens; identity for runtime; agent traits in SIEM.

**Specific threats of agents**

**Eight Threats and Their Mitigations**

| Threat | Description | Mitigations |
| --- | --- | --- |
| Direct prompt injection | user tries to make agent ignore rules | guardrails; authorization does not depend on prompt |
| Indirect injection | indexed document or tool response contains instructions | content treated as data; limited tools; separate instruction and data channels |
| Agency excess | functionality, permission or autonomy (OWASP LLM06) | minimum catalogue; scopes; HITL |
| Confused warehouse | the agent uses its authority for what the user could not | delegation with permissions intersection |
| Token passthrough | server passes token without validating audience | prohibited by MCP; token exchange |
| Exfiltration by exit | sensitive data in response or URL | masking; domain allowlist; no arbitrary links |
| SSRF via discovery | OAuth metadata pointing to internal addresses | URL validation; private track blocking; exit proxy |
| Secrets in Context | keys in prompts or logs | secret safe; tokens out of model context |

**Registration of execution, LGPD and AI governance**

O **execution record** by task is a single artifact that serves security (forense), compliance (decision review, art. 20 of LGPD) and SRE (diagnostic). Fields: Correlation ID; subject; actor; channel; version of instructions and model; interpreted intention; consulted sources (with version); tools called (masked arguments); policy decisions; interruptions and responses; effects (protocols in the registration system). Reconstruction requires old versions of instructions and content to remain available for the audit period **[INFERENCE]**.

**Data classification applied to agents **[RECOMMENDATION]****

| Class | Does it fit into the context of the model? | Does it appear in the answer? | Detention in logs |
| --- | --- | --- | --- |
| Public or internal | Yes | Yes | default |
| Common staff | Yes, the holder himself | yes, to the holder himself | short |
| Sensitive personnel (LGPD, Art. 5, II) | only the minimum, with registered purpose | summary to the holder himself | minimum or masked |
| Business confidentiality | no, except authorised tool | no | according to policy |
| Secrets | **never** | **never** | **never** |

Explainability, here, is not explaining the weights of the model: it is telling the collaborator and the auditor which sources support the answer, which rules were applied and by whom, which data the collaborator was used and what the agent did, with which authorization. That gets a lot more direct when the rule is **outside the model** **[INFERENCE]**. In AI governance, the NIST AI RMF gives the risk structure, ISO/IEC 42001 serves those seeking certification and the OWASP Top 10 for LLMs is the technical checklist **[FATO]**.

Governance without stopping delivery **[RECOMMENDATION]**: automatically verifiable standards (classification of validated IC tools, leak tests, assessment suite with thresholds, policy as code); approval by risk class; review after delivery, by sampling, for knowledge responses, and review before for actions.

Autonomy proportional to evidence is the same principle as [Trust Engineering](https://mauricio.issei.com.br/en/engenharia-confianca).

Cases **[RECOMMENDATION]**

#### The agent within the process, and the human exceptions

The agent is a **intelligent interface on explicit processes**Not a replacement for them. Corporate processes accumulate three types of knowledge: explicit rule (“dependent up to 21 years, or 24 if student”), tacit rule (“in practice, HR accepts the school statement by the end of the month”) and judgment (“I will consult the legal”). The agent tends to handle the first one well. In view of the second, it can produce a plausible version, but not verified; in the third, it can present as a decision something that requires a responsible **[INFERENCE]**.

That's why architecture separates four responsibilities, each with its own owner and tests: **interaction** (agent understands, collects, explains, confirms and accompanies), **orchestration** (workflow: state, stages, timers, human tasks, compensation), **decision** (area: eligibility, calculations, validations) and **log** (registration system). The agent can switch models without changing the rule; the rule can change without rewriting the agent.

##### Exceptions are first class states

##### What every predictable exception has

- type (unreadable document, out of date, conflict of segregation of functions, if not foreseen);
- row with owner and SLA;
- structured context transferred (intention, data, attempts, sources, motive);
- return path to automated flow.

##### Handoff triggers

- the rule requires human (privileged access);
- low confidence in interpretation after two attempts to clarify;
- sensitive theme (harassment, mental health, shutdown): offer the person *immediately*;
- explicit request: “I want to talk to a person”;
- persistent technical failure;
- case outside the documented rules.

**[FATO]** For **user's own confirmation**, the interruption of AG-UI is appropriate: the execution ends and the response comes in new execution. **[INFERENCE]** For **third party approval** (manager, HR), the right place is the workflow engine, with human task and timers: the interruption is short and focused on the present user, and approval may take days. The SLA belongs to *Case*, not to the staff member — the staff member informs the time limit, does not create it.

The agent also works as **process sensor** **[INFERENCE]**: the questions it does not solve and the exceptions it sends reveal ambiguous rules, API gaps and unnecessary steps. This feedback is a useful by-product of the agentic layer — as long as there is owner to receive it.

**What the agent does and doesn't do at every stage**

**Nine stages of the process**

| Step | The agent does. | The agent doesn't. | Mechanism |
| --- | --- | --- | --- |
| Trigger | acknowledges the intention and identifies the process | invent a non-existent process | EXP service catalogue |
| Preconditions | consultation eligibility | decide eligibility | Rule API |
| Collection | pre-fill with system data; asks only what is missing | infer critical data | structured components, state AG-UI |
| Validation | clearly shows errors | ignore validations | field validation |
| Submission | begins the process with idempotence, after confirmation | submit actions with no confirmation | interruption AG-UI + tool |
| Approval | notifies and summarizes the context for the approveer | approve on behalf of the approveer | human task in workflow |
| Exception | detects, explains and forwards with context | resolve the exception alone | exception queue |
| Monitoring | consults the state and explains | promise deadlines outside the SLA | Workflow Status API |
| Closure | confirms the result and offers next steps | declare completed what was only accepted | completion event |

**Four integration patterns and what to automate**

- **Agent as initiator:** collect and initiate an existing process — most transactional services.
- **Agent as human stage assistant:** summarizes, suggests and prepares for the human to decide — approvals, documentary analyses.
- **LLM Step within the workflow:** the workflow calls the model for a delimited task (classify, extract, summarize). It matches what Anthropic calls *workflow* (predefined code paths) and tends to be the lowest risk for regulated processes **[INFERENCE]**.
- **Agent as orchestrator:** decides the sequence between services — only for low risk journeys and high variability, with clear limits.

**Universal examples of HR and IT **[RECOMMENDATION]****

| Case | Volume | Variability | Risk | Suggested approach |
| --- | --- | --- | --- | --- |
| Consultation of holiday balance or hours | high | low | low | read tool; direct response |
| Request for a holiday | high | low | medium | Initiating agent + confirmation |
| Open call for IT | high | high | low | screening agent (LLM step) and opening |
| Inclusion of dependents | medium | medium | high (sensitive data) | initiator agent + document + workflow with validation |
| Request for access | high | medium | high | agent collects and justifies; mandatory human approval |
| Onboarding | medium | medium | medium | orchestrated workflow; agent as guide |
| Change of post | low | high | high | systemic workflow; agent only informs |
| Shutdown | low | high | Too high | human channel; agent only guides |

Intentions that cross domains (“I’m moving around” involves HR, benefits, facilities, IT and sheet) are **journeys** EXP, with named owner, implemented as orchestration workflow. The agent conducts the conversation and shows progress; *never improvise the sequence* Every conversation.

**Use AI to compensate poorly defined process** is to put an agent in front of a tacit rule, without owner or inconsistent, hoping that the model “resolves”. The result is the tacit rule applied inconsistently, now on a scale. The alternative is to use the discovery of the project to explain rules, exceptions and owners before automating; the agent can even help by analyzing calls and conversations.

**Intent-oriented experience: modes, confirmation and accessibility**

The mature experience **combines modes** instead of exchanging everything for chat: navigation, search, conversation, structured component and proactive notification. The intention box is the preferred input, but navigation and search remain; remove menus before the agent proves resolution reduces confidence **[RECOMMENDATION]**.

- **Confirmation before effect:** the confirmation component is fixed and non-parametric in the essential structure — highlighted critical values, simple language, clear primary action and possibility of editing without restarting.
- **Calibrated trust:** cite sources with name, version and date; admit uncertainty; not simulate excessive empathy in sensitive topics.
- **Handoff:** explain why the case goes to a person, transfer structured context, inform queue and SLA, allow to resume the conversation.
- **Accessibility:** `aria-live="polite"` moderation; streaming announced by step, not by token; explicit focus management when components are replaced; only certified components of the catalog; alternative paths by navigation.
- **Risks of UX:** opaque text box; excessive anthropomorphization; long answers when a button would suffice; inconsistency between channels; advanced users required to talk to what they did in two clicks.

Papers **[RECOMMENDATION]**

#### Twelve lenses, an architectural board

An agentic journey crosses disciplines that rarely talk. The architecture board analyzes the journey by **each lens separately** before consolidating; conflicts resolve with the patterns of Decisions. The table shows the question that only every paper does and what the journey loses if it is ignored.

**Role, own question and consequence of omission.**

| Paper | You ask what only he does | If ignored |
| --- | --- | --- |
| Enterprise Architect | What business capabilities does the platform expose and who owns each one? | agent becomes improvised integrator |
| Integration Architect | API, event or workflow for each interaction? | coupling and inconsistent states |
| Product Strategist | What intentions are worth more and how do we measure resolution? | technology looking for trouble |
| Process / BPM | Is the rule explicit, with owner and exception line? | Inconsistency automation |
| UX Architect | How does the collaborator trust, confirm and resume? | actions without clear consent |
| Front-end Architect | How to compose dynamic UI without breaking the design system? | Arbitrary, inaccessible IU |
| AI Architect | What agent, with what tools and what evaluation? | hallucination and excess agency |
| Content Strategist | What is the canonical source, duration and owner? | RAG on content without governance |
| Search Architect | Does the search respect permissions in the index? | oversharing leak |
| Security / IAM | With what identity does the agent act and with what scope? | generic service account |
| Data & AI Governance | Legal basis, retention, inventory of use cases? | non-compliance with LGPD |
| SRE / Platform | How do we measure quality, cost and latency by intention? | quality silent incidents |

Decisions **[RECOMMENDATION]**

#### Trade-offs, anti-patterns and technological matrix

There is no unique ideal architecture. The conflicts below are real and are not eliminated; what is chosen is **the mechanism that balances them**. Each card says what's at stake and how architectures usually handle it.

##### Twelve trade-offs

##### Flexibility × Governance

The more free the platform, the harder it is to keep verifiable security, content and compliance.

**Balance:** verifiable standards instead of case-by-case approval; risk proportional approval; “paved paths”, where doing right is easier than wrong.

##### Autonomy × Control

Autonomy makes the agent useful; control makes it acceptable.

**Balance:** autonomy levels by class of action; formal interruptions; out-of-model controls, with permission in downstream systems.

##### Customization × Consistency

Each employee sees something different; the organization needs a recognizable, bearable and auditable experience.

**Balance:** customize content and order, not structure and rules; fixed templates for high volume intentions and free composition only on the long tail.

##### Generating UI × Design system

Generative UI promises custom screen; design system exists for consistency, accessibility and branding.

**Balance:** catalogue composition, not free generation. The design system becomes the agent's vocabulary.

##### Speed × Compliance

AI evolves in weeks; formal compliance cycles take months.

**Balance:** compliance embedded in the platform (classification, masking, retention, execution record); initial low risk scope; frameworks recognized as NIST AI RMF and ISO/IEC 42001.

##### Automation × Human-in-the-loop

Each confirmation reduces gain; each humanless automation increases risk.

**Balance:** HITL where error is expensive or irreversible; efficient confirmation, with clear summary; progressive automation by evidence.

##### Decentralisation × Governance

Autonomous domains accelerate; governance needs a vision of the whole.

**Balance:** central catalogues with distributed property; mandatory minimum standards (identity, telemetry, idempotence, classification) and freedom in the rest.

##### Micro-frontends × Operational complexity

They give deploy autonomy and charge with shared dependencies, integration tests and consistency.

**Balance:** adoption conditioned the organizational need measured; modular monolith as standard.

##### RAG × Reliability

The RAG gives fluent responses; fluency is not accuracy.

**Balance:** governance at source; verifiable citations; lean context; continuous evaluation; rule in domain — the document explains, API decides.

##### Autonomy × Auditability

The more the agent decides on his own, the harder it is to explain later why something happened.

**Balance:** complete execution record; business decisions outside the model, so that the explanation is a rule; explicit delegation (RFC 8693).

##### Personalization × Privacy

The deeper the customization, the more data it uses; the LGPD requires purpose, need and transparency.

**Balance:** customize by context and state before customizing by inference; minimize the context of the model; be transparent; optional and deleteable long-term memory.

##### Possible Consistency × Experience

Distributed architectures accept delays; the collaborator expects to see the result on time.

**Balance:** honest intermediate states (“registered, awaiting approval”, not “ready”); progress activities; reading of the BFF’s own writing.

##### Three additional paradoxes

##### Platform agent × independent agent

When the experience runs on a SaaS platform, the native agent quickly integrates into its data, but becomes attached to the supplier and sees little of the other systems. The independent agent sees the entire ecosystem, but requires building integration, identity and UI.

**In practice** **[INFERENCE]**: hybrid architectures — platform agents for tasks within it and an independent entry agent that delegates them via A2A.

##### Adoption of protocols × Stability

Adopting AG-UI, MCP and A2A early brings interoperability; specifications still change incompatiblely. MCP review 2026-07-28, for example, removed sessions and startup handshake **[FATO]**.

**In practice:** internal adapters that isolate the protocol, contract tests and follow-up of depreciation policies (MCP now has a minimum window of 12 months).

##### Quality × Cost

Larger models, more context and more steps increase quality and cost.

**In practice:** complexity routing (smaller model for classification, higher for difficult cases), cache of knowledge responses by segment, budget by intention and cost alerts.

##### Seventeen anti-patterns

Generic risks of any organization in this trajectory, not attributed to any in particular; the excerpts “how it appears” are illustrative. The severity is that of the study.

01 High

##### Agent as new ESB

**How it appears**

a central “corporate agent” with dozens of tools that transform data, decide routing and coordinate systems; a single team owns everything.

**Because it's trouble**

reproduces the neck of the central bus and adds probabilistic behavior.

**How to detect**

tools that call various systems and decide something; rules in prompts.

**Alternative**

the agent is a channel; tools are fine adaptors of the domains; aggregation in the BFF; processes in the workflow engine.

02 High

##### Business logic within the LLM

**How it appears**

the prompt contains “collaborators over 12 months are entitled to...”; the agent decides eligibility by reasoning.

**Because it's trouble**

inconsistency between executions, duplicate rules that differ from the system, unauditable explanation.

**How to detect**

numbers, deadlines and eligibility conditions in the system instructions.

**Alternative**

rules in domain services or rule engines, consulted by tool.

03 Review

##### Unrestricted agent access to APIs

**How it appears**

an accreditation with wide access “not to stop the pilot”.

**Because it's trouble**

excess functionality, permission and autonomy (OWASP LLM06); an indirect injection gains the power of the credentials.

**How to detect**

wildcard scopes; generic tools such as `executar_consulta`; the same credentials for all.

**Alternative**

minimum catalogue of narrow tools; token delegated by user; authorization at point of data.

04 High

##### RAG as governance substitute

**How it appears**

“we do not need to organize the rules; the AI finds”.

**Because it's trouble**

the RAG recovers the most similar, neither the current nor the applicable; the answer is fluent and wrong, and no one answers for it.

**How to detect**

index powered by “all PDFs”; no valid metadata; no owner of content in the project.

**Alternative**

governing at source; the GRA reflects this governance.

05 Alta

##### Vector bank without metadata

**How it appears**

Chunks and embeddings without permission, validity, applicability or origin.

**Because it's trouble**

impossible to filter by public or index permission; the filter ends up applied afterwards — or delegated to the model.

**How to detect**

the index schema has only `id`, `texto` and `vetor`.

**Alternative**

hybrid index with metadata and first class ACLs; pre-filter by identity.

06 Alta

##### Generate arbitrary UI

**How it appears**

the model generates HTML, CSS or JavaScript rendered directly.

**Because it's trouble**

injection surface, unpredictable accessibility, inconsistency, impossible to certify.

**How to detect**

`innerHTML` with model content; no component catalog.

**Alternative**

declarative composition on approved catalog, or IU isolated in sandbox, with props validation.

07 Average

##### Micro-frontends without need

**How it appears**

adopted because “it is modern architecture”, with one or two teams.

**Because it's trouble**

costs of dependencies, integration tests, performance and consistency without the benefit of independent deploys from various teams.

**How to detect**

less than three teams in the shell; unmeasured release bottleneck.

**Alternative**

modular monolith with clear borders.

08 Average

##### Turn everything into microservices

**How it appears**

rewrite stable registration systems in smaller services as a prerequisite for AI.

**Because it's trouble**

years without value; distributed complexity. The agent needs contracts, not microservices.

**How to detect**

The AI plan depends on a rewrite.

**Alternative**

expose existing API capabilities; strangulation (*strangler Fig*) only when replacement is necessary.

Average 09

##### Events where a simple API would suffice

**How it appears**

synchronous queries modeled as pairs of order and response events.

**Because it's trouble**

latency, difficult correlation, painful clearance, no gain of decoupling.

**How to detect**

events awaiting response.

**Alternative**

Synchronous API for immediate queries and commands; events for facts with multiple consumers.

10 Average

##### Multi-agent without need

**How it appears**

“an orchestrator agent”, “HR agent”, “revisor agent” for a scope that an agent with filtered tools would solve.

**Because it's trouble**

multiplies latency, cost and fault points; hinders clearance and evaluation. The recommendation is to start with the simplest solution.

**How to detect**

More than one agent without a clear border owner.

**Alternative**

an agent with a catalogue filtered by intention; separate only with a real border owner, policy or supplier.

11 Average

##### Confusing Chatbot with Agent

**How it appears**

a bot of questions and answers sold as “alone agent” — or an agent with writing tools governed as chatbot.

**Because it's trouble**

wrong expectations and, more serious, insufficient controls for those performing actions.

**How to detect**

control doesn't follow what the system can do.

**Alternative**

use taxonomy (chatbot, copilot, RAG, agent, agent with tools, workflow with agents, multi-agent) and proportional controls.

12 High

##### Confused vector search with knowledge

**How it appears**

“we have a vector bank, so we have a knowledge base.”

**Because it's trouble**

knowledge requires validity, applicability, authorship and relationships; semantic similarity does not capture any.

**How to detect**

No metadata, no owners.

**Alternative**

knowledge = governed content + metadata + relationships + hybrid search + evaluation.

13 Average

##### MCP as universal integration solution

**How it appears**

“one MCP server in front of each system and ready”.

**Because it's trouble**

the MCP standardizes how the agent discovers and calls tools; does not solve domain contract, consistency, long processes or events — and the specification still changes.

**How to detect**

without BFF, APIs or workflows from behind.

**Alternative**

MCP as agent interface ↔ tools, on a conventional integration layer.

14 High

##### AI to compensate ill-defined process

**How it appears**

an agent in front of a lawsuit with tacit rule, without owner or inconsistent.

**Because it's trouble**

automates inconsistency and hides governance gaps behind a fluent interface.

**How to detect**

several-day processes that depend on the state of the conversation.

**Alternative**

use the discovery of the project to explain rules, exceptions and owners.

15 Critical

##### Token passthrough and generic service account

**How it appears**

the agent passes the user token to any API, or uses a unique service account for everything.

**Because it's trouble**

the MCP prohibits passthrough: bypasses controls, compromises the audit trail and breaks trust borders. The generic account deletes the “in whose name”.

**How to detect**

the agent passes tokens or shares credentials.

**Alternative**

token exchange with delegation (subject + actor) and hearing by appeal.

16 Average

##### Remove navigation before proving agent

**How it appears**

The home becomes just a box of conversation.

**Because it's trouble**

who knows what he wants loses efficiency; the agent's faults are left with no alternative; trust falls.

**How to detect**

No equivalent navigation path.

**Alternative**

coexistence: agent as preferential entry, navigation always available; gradual removal by evidence of use.

17 Average

##### Measure success by volume of conversations

**How it appears**

the project metric is “number of interactions with the assistant”.

**Because it's trouble**

more conversations can mean more confusion; encourages engagement, not resolution.

**How to detect**

the main metric is volume of use.

**Alternative**

resolution by intention, time to resolution, recount, perceived effort.

##### Quick detection checklist

- Are there business rules in promps?
- Does any tool have a wild scope or is it generic?
- Does the index have metadata of permission and validity?
- Does the model generate rendered marking directly?
- Is there more than one agent without a clear border owner?
- Does the agent pass on tokens or use shared service account?
- Do several-day lawsuits depend on the state of the conversation?
- The main metric is volume of use?

Any “yes” indicates an anti-pattern to treat before broadening the scope.

**Technology matrix: what is needed and what is alternative **[INFERENCE]****

The matrix **compares, does not elect**: necessary *capabilities*; technologies are alternatives to implementation.

**Required capacity × implementation alternatives**

| Required (capacity) | Implementation alternatives |
| --- | --- |
| Federated identity with delegation | any IdP with OAuth 2.x and token exchange or equivalent mechanism |
| Authorization at data point | RBAC + ABAC, ReBAC, OPA or Cedar engines, rules in the registration system itself |
| Contract APIs for used capabilities | REST, GraphQL, gRPC; via gateway and BFF or directly |
| Durable processes with human stages | Temporal, BPMN engines, native SaaS system or platform workflow |
| Content with metadata, duration and permissions | ECM/CSP, CMS headless, productivity platforms |
| Hybrid search with permission filters | Elasticsearch, OpenSearch, managed services, combinations |
| Interaction protocol agent ↔ IU | AG-UI, own protocol, SaaS platform features |
| Generating IU governed | A2UI, MCP Apps, Open-JSON-UI, own design system schema |
| Standard tool interface | MCP, native framework function calls, direct integration |
| End-to-end observation | OpenTelemetry with any compatible backend |
| Continuous assessment | various evaluation frameworks, own tools |

**These are not requirements:** micro-frontends, Kafka, service mesh, dedicated vector bank, multi-agent, full MACH. Each makes sense in specific contexts.

Operation **[RECOMMENDATION]**

#### Operate an agent: strokes, SLOs quality and cost

In traditional operation, a healthy system is an available and fast system. On an agent-oriented platform it may be available, fast and **wrong**: responding with a policy revoked, choosing the wrong tool, going into loops that multiply cost or slowly degrade after a model change. They are. **silent incidents**, invisible to the infrastructure panels.

##### Three observability plans

##### Services

*Are you up and running?* RED/USE metrics, logs, distributed dashes. Owner: SRE and service teams.

##### Agent

*What did the agent do and why?* Execution spans, steps, tool calls, tokens, model latency, policy decisions. Owner: AI platform.

##### Quality and experience

*Was the result good?* Ratings, groundedness, feedback, intent resolution, DEX. Owner: product, content and AI.

**[FATO]** OpenTelemetry maintains semantic conventions for GenAI (still evolving), and MCP review 2026-07-28 documents the spread of `traceparent` between agent and tool server. The `RUN events_*` e `STEP_*` from the AG-UI delimit executions and serve as anchor for experience side spans **[INFERENCE]**. Personal data in traces: prompts and full answers go to restricted storage and short retention, or are masked.

##### SLOs that include quality and cost

**Examples of objective, calibrating by intention **[RECOMMENDATION]****

| Family | Indicator (SLI) | Example of objective |
| --- | --- | --- |
| Availability | executions without `RUN_ERROR` by platform failure | ≥ 99,5% |
| Latency | time to the first token | p95 < 1.5 s |
| Latency | shift with up to 2 tools | p95 < 8 s |
| Quality | knowledge responses supported by sources (sample) | ≥ 95% |
| Quality | permission leakage in continuous tests | 0 |
| Value | humanless resolution in the intentions empowered | ≥ baseline per intention |
| Cost | cost per resolved intention | ≤ budget per intention |

When **quality error budget** it bursts — for example, groundedness below target for two weeks —, changes in prompt, model and tool catalog are frozen until correction. It is the same discipline that already exists for availability, applied to quality.

**[INFERENCE]** An agent chaining tools inherits availability *combined* of dependencies: three systems with 99.5% each leave a response that depends on the three around 98.5%. Hence the graceful degradation by tool, reading projections and caches, the fallback of previously evaluated model and, finally, traditional navigation.

**Agent-specific metrics**

**Eight categories**

| Category | Metric | Why Does It Matter |
| --- | --- | --- |
| Latency | time to the first token; full shift; by tool; model | user perception and diagnosis of bottleneck |
| Cost | tokens per turn, conversation and resolved intention; cost per model | budget and loop detection |
| Tools | error rate, timeouts, relays, open circuits | health of dependencies |
| Agent | steps per task, replanning, tasks that reach the limit of steps | efficiency and loops |
| Retrieval | empty results, average score, distribution of sources, age of content cited | quality of knowledge |
| Security | policy denials, injection detections, abandoned interruptions | risk posture |
| Quality | sampling groundness, evaluated correction, negative feedback by reason | perceived quality |
| Experience | resolution by intention, scaling, recount, abandonment | value delivered |

Measure by **intention**, not by the screen: with the dynamic interface, time on the page and clicks lose meaning. Experience metrics are resolution rate, time to resolution, perceived effort, resolution shifts, editing rate in confirmations, step abandonment, scheduling and recount in 7 days. Combined with the telemetry and feeling of DEX tools, they form an independent view of the interface shape **[RECOMMENDATION]**.

**Agent incidents and specific runbook**

**Six types of incident**

| Type | Example | Detection |
| --- | --- | --- |
| Availability | model provider out | error metrics |
| Latency | slow system drops shifts | tool latency |
| Quality | reindexion broke the chunking; answers without source | continuous evaluation, feedback |
| Security | restricted content leak | continuous tests of permission, reports |
| Cost | tool loop multiplies tokens | cost alerts per conversation |
| Behavior | the agent started to perform action without confirmation after changing the prompt | regression tests, audit |

1. **Kill switches** by tool, intent and whole agent.
2. **Configuration Rollback:** instructions, catalog and model version are versioned and reversed.
3. **Reproduction:** the execution record allows the execution of the case with the same context in test environment.
4. **Communication:** if there was a wrong response about a policy, evaluate to notify the affected.
5. **Postincident:** classify the cause by layer (content, search, model, tool, process, policy).

**Continuous assessment and internal platform**

- **Production evaluation:** sampling with human evaluation; automatic evaluator calibrated by humans; periodic synthetic tests; continuous permission tests with low privilege identities; feedback analysis; canary and A/B configuration.
- **Internal platform:** paved paths (tool server template with delegated authentication, idempotence, telemetry and testing); catalog of tools and components with owner, version, classification and SLO; evaluation environments with simulated systems; model cost budgets per domain.
- **[INFERENCE]** Maturity: SRE and distributed observability are mature; observability and evaluation of agents are in consolidation.

For service operation and SRE on another scale, see [Service Operations 2.0](https://mauricio.issei.com.br/en/service-operations-2-0).

Roadmap **[RECOMMENDATION]**

#### Six phases, seven trails and a critical path

Phases have **passing criterion**; tracks advance in parallel and at different rhythms. There are no deadlines: the duration depends on the current state, which only the discovery reveals. The entire roadmap is the recommendation of the study and does not describe the plan of any organization.

Delegated Identity (T2) and content governed with permissions (T3) are usually the slowest dependencies because they involve IdP providers, legacy systems and content owners of various areas **[INFERENCE]**. Starting them in phase 0 prevents them from blocking phases 3 and 4.

**Seven tracks × six phases, with the criteria for crossing the footer. The T2 and T3 lines are the critical path.**

| Track | Phase 0 Discovery and baseline | Phase 1 Minimum reasons | Phase 2 AI-Enhanced on pilot | Phase 3 Agent with reading | Phase 4 Actions with confirmation | Phase 5 Expansion and autonomy by evidence |
| --- | --- | --- | --- | --- | --- | --- |
| T1 · Product and journeys Product Strategist | ranking of the 50 main intentions; baseline resolution, time and effort; 2 or 3 pilot journeys | — | resolution measurement and counter-baseline recount | — | edition rate on confirmations; satisfaction | repeats phases 1–4 in new journeys; measures coverage of intentions and global resolution |
| T2 · Identity and authorizationCritical pathSecurity / AMI | IdP inventory and protocols; feasibility of token exchange; current authorisation model | delegated token standard; policy engine for pilot APIs; specified execution log | — | token delegate in production; reading audit | incremental elevation of scope; resettlement for sensitive actions | repeats phases 1–4 on the new journey |
| T3 · Content and knowledgeCritical pathContent / Search | pilot day content inventory; metadata diagnosis and permissions | canonical source, duration, owner and permissions; life cycle events | hybrid search with ACLs in the index; continuous leakage tests | — | — | repeats phases 1–4 on the new journey |
| T4 · Capacity and integration Enterprise / Integration | inventory of API registration and maturity systems | APIs with contract; Agent channel BFF; workflow for long processes | — | — | start of workflows per tool; honest intermediate states; event notifications | repeats phases 1–4 on the new journey |
| T5 · UX experience / Front-end | evaluation of system design and experience platform | initial catalogue of agent components (confirmation, progress, sources, handoff) | question and answer with preserved sources, feedback and navigation | interaction protocol (e.g. AG-UI encapsulated); data components (cards, tables) | Generating UI restricted to catalogue; fixed confirmation; formal interruptions | evolves the catalog guided by unmet intentions; additional channels |
| T6 · AI and AI Architect agents | analysis of existing AI assistants, if any (catalogue, technology, handoff) | pilot day evaluation set | RAG with citations; assessment of groundedness | agent with reading tools; step limits and cost | idempotent writing tools | action class autonomy (“execut and notify”) based on evidence; domain agents (A2A) where there is real border |
| T7 · Governance and operation Governance + SRE | current AI policy; data classification; observability stack | case of use in AI inventory; OpenTelemetry in Pilot APIs | Quality SLOs; intent panel; sample review | correlated agent traits; cost alerts | Sampling audit review; tested kill switches; agent incident runbook | repeats phases 1–4; measures cost per resolved intention |
| Passing criterion | pilot days chosen by volume, value and viability; known priority gaps | RAG readiness checklist met in pilot scope; SLO pilot APIs | groundedness and recovery above thresholds; zero leaks in tests; measured resolution improvement | tool error and latency within SLO; security and compliance validated audit | acceptable action error rate for a defined period; no action without recorded confirmation; human exceptions with context | each expansion of autonomy requires evidence of safety and quality |

*Figure 7 · Grid phases × trails. With JavaScript, the buttons faint the other lines (continue in the document and accessibility tree); without JavaScript, the table is complete.*

##### Six roadmap principles

1. **Problem before technology:** each phase begins with intentions prioritized with data.
2. **Foundations before autonomy:** identity, contracts and governed content precede the agent's actions.
3. **Vertical Scope:** advance journey by journey, not layer by layer throughout the company.
4. **Early visible value:** each phase delivers something that the collaborator perceives.
5. **Reversibility:** Kill switches, coexistence with navigation, encapsulated protocols.
6. **Evidence to expand autonomy:** a level only rises with safety and quality metrics.

**How to Choose the Pilot Journey**

**Criteria and suggested weight **[RECOMMENDATION]****

| Criteria | Weight | Why? |
| --- | --- | --- |
| Volume of intentions | high | perceptible value |
| Low risk of action | high | safety in learning |
| Available APIs | high | viability |
| Governable content | medium | quality of responses |
| Engaged process owner | high | receives feedback and solves exceptions |
| Low data sensitivity | medium | reduces the initial compliance load |

**[HYPOTHESIS]** “Happiness” (high volume, clear rule, moderate risk) and “IT call” (high volume, low risk) tend to be better pilots than “dependent inclusion” (sensitive data) or “access solicitation” (security risk).

**Roadmap risks and phase metrics**

**Risks and mitigations**

| Risk | Mitigation |
| --- | --- |
| “Invisible” foundations lose sponsorship | early deliver improved search (phase 2) as visible value |
| Pressure for jumping to stock | explicit and agreed pass criteria with sponsors |
| Change of protocol specification | internal adapters; contract tests |
| Supplier of a SaaS platform launches own agent during the program | explicit decision agent of the platform × independent, revisited at each stage |
| Central Team Dependency | paved paths and distributed tool property |

**Main metrics per phase**

| Phase | Metrics |
| --- | --- |
| 0 | inventory coverage; defined baseline |
| 1 | % of pilot content with mandatory metadata; SLO APIs |
| 2 | recall@k, groundedness, leaks (zero), resolution |
| 3 | turn latency, tool error, cost per conversation |
| 4 | action errors, editing rate, exceptions solved in SLA, satisfaction |
| 5 | intent coverage, overall resolution, cost per intention solved |

Readyness **[RECOMMENDATION]**

#### Agentic readiness per journey

Point **a journey** of its context — not the entire portal — in ten criteria: 0 = absent, 1 = partial, 2 = complete. The total goes from 0 to 20 and suggests what the journey tends to endure today. The thresholds are a proposal of the study, not yet validated in the field **[HYPOTHESIS]**. The calculation happens in your browser: nothing is sent and nothing is saved.

Unanswered criterion counts as absent (0).

- Intent prioritized with baseline: 0 missing · 1 partial · 2 complete

- Explicit process with owner: 0 absent · 1 partial · 2 complete

- APIs with contract: 0 missing · 1 partial · 2 complete

- Delegated identity: 0 absent · 1 partial · 2 complete

- Content governed: 0 absent · 1 partial · 2 complete

- Permit search: 0 missing · 1 partial · 2 complete

- Components in the catalogue: 0 missing · 1 partial · 2 complete

- Assessment set: 0 absent · 1 partial · 2 complete

- Observability and audit: 0 absent · 1 partial · 2 complete

- Governance approval: 0 absent · 1 partial · 2 complete

The button requires JavaScript. Without it, do the sum of the points by hand and compare with the table of tracks next to it.

Result

– / 20

Answer the criteria to see the track.

The track is an indicator, not an approval: gap in delegated identity or governed content blocks the stages 3 and 4 of the roadmap, whatever the total. Nothing leaves the navigator and nothing is persisted.

**Tracks**

| Total | Reading |
| --- | --- |
| 0 to 9 | little ready for AI: working foundations |
| 10 to 15 | ready for RAG and read tools if listed gaps are not blocked |
| 16 to 20 | candidate for actions with confirmation, provided that delegated identity, governed content and governance are not at 0 |

**Dimension maturity metrics and regression signals**

**Twenty metrics and the stage at which they start importing **[RECOMMENDATION]****

| Size | Metric | How to measure | Stage |
| --- | --- | --- | --- |
| Product | human-free resolution by intention | telemetry + recount | 2 |
| Product | time to resolution | from request to result in registration system | 2 |
| Product | perceived effort | short post-interaction search | 2 |
| Integration | % of priority capabilities with API and versioned contract | catalog | 3 |
| Integration | % of capabilities with published SLO | catalog | 3 |
| Case | % of priority processes with owner, explicit rule and queue | inventory | 3 |
| Content | % of content indexed with duration, owner and permission | metadata validation | 4 |
| Content | time of revocation of the index | events | 4 |
| Search | recall@k and nDCG in the evaluation set | evaluation | 4 |
| Search | leaks in permission tests (meta: zero) | continuous tests | 4 |
| AI | sample groundness | evaluation | 4 |
| AI | accuracy of tool selection | evaluation | 5 |
| Security | % of tools with delegated token and minimum scope | catalog | 5 |
| Security | % of shares with registered confirmation | audit | 5 |
| UX | % of agent screens composed of catalogue components only | rendering telemetry | 5 |
| UX | Editing fee in confirmations | telemetry | 5 |
| Operation | % of executions with trace end to end | observability | 4 |
| Operation | compliance with quality SLOs | panel | 5 |
| Cost | cost per resolved intention | observability | 4 |
| Governance | % of AI use in approved inventory | inventory | 4 |

**Regression signs:** drop in groundedness after changing model or chunking; increase in editing rate in confirmations (the collection worsened); increase in staggering by “I did not understand”; increase in cost by intention without resolution gain; increasing average age of the quoted content (curacy stopped).

The readiness of a *site* to be read by agents, on another scale, is the theme of [Agent Ready](https://mauricio.issei.com.br/en/agent-ready).

Critical questions

#### Thirty questions in five groups

Each answer brings the conclusion and the seal that says how much it sustains itself. Open the door; the rest is collected.

##### 1 · Experience, protocols and interface (1 to 8)

**1. What differentiates a modern intranet from an EXP?**

**[INFERENCE]**

The intranet informs and forwards; the EXP executes and follows. The intranet organizes pages and audiences and measures reach; EXP organizes services and journeys on registration systems, measures resolution and effort and maintains the context of the collaborator in various channels.

**2. Does an EXP need to be composable?**

**[INFERENCE]**

Not necessarily. Componibility is paid for with many domains, many channels and strategy to exchange suppliers. For agents, the real requirement is that capabilities are exposed by contract: a suite with good APIs serves better than a complicable architecture without stable contracts.

**3. Is MACH an architectural requirement or possible strategy?**

**[RECOMMENDATION]**

Possible strategy. API-first and headless are for agents; microservices only where there is organizational border. It is worth remembering that the MACH Alliance is an association of suppliers, and its material is market positioning.

**4. Where does AG-UI really fit?**

**[FATO]**

Between the agent runtime and the application the user operates. MCP connects agent and tools, A2A connects agents, AG-UI connects agent to user. It doesn't fit into integration with registration systems or authorization.

**5. AG-UI is a protocol of UI, integration or interaction?**

**[FATO]**

Interaction. The documentation describes it as the connection of bidirectional runtime between agent and application and distinguishes it from the specifications of generative IU. It doesn't define components or connect systems.

**6. What is the relationship between AG-UI and generative UI?**

**[FATO]** **[INFERENCE]**

Channel and vocabulary. Generative UI specifications define *What?* render; AG-UI transports these orders to the client and brings the actions back. In practice, AG-UI frontend tools can request the rendering of catalog components.

**7. How to preserve determinism in a generative interface?**

**[RECOMMENDATION]**

Determinism where it matters, adaptation in the rest. They are deterministic: the rendering of each component, the validation of props, the execution of actions and components of confirmation and legal notice. They are adaptive and restricted: the choice of the component within the catalogue, the explanatory text and the composition within templates. High volume intentions use fixed templates; the free composition stays for the long tail.

**8. How does a system design become consumable by agents?**

**[RECOMMENDATION]**

Turning components into typed and described tools into a Component Registry: description of when to use and not to use; JSON Pros schema; issued actions and side effect; required context; component accessibility audit; standardized tokens (the format of the W3C Design Tokens Community Group has been stable since October 2025); and assessments that verify whether the agent chooses the right component.

##### 2 · Knowledge and search (9 to 11)

**9. What is the relationship between ECM, CSP, headless, search and RAG?**

**[INFERENCE]**

A chain in which each link inherits the quality of the former and cannot correct it. ECM keeps governed records; CSP exposes them as services; headless structure experience content for various channels; the search finds the right passage for the right person; the RAG generates the reasoned answer.

**10. What needs to be structured before implementing RAG?**

**[RECOMMENDATION]**

Six blockers: canonical source by type of content; explicit and exportable permissions to the index; status and validity; owner of each content; classification of information with rule of use by AI; evaluation set with real questions. Taxonomy, applicability metadata, section structure, life cycle events and deduplication are strongly recommended.

**11. How to implement and verify permission-aware retrieval?**

**[RECOMMENDATION]**

With permission prefilter in the index, using IdP-resolved identity: permissions as metadata for each chunk; filter in the query, never after the model saw the content; synchronization by events with propagation SLO; continuous leak tests with low privilege identities; overshare review before indexing.

##### 3 · Agents and integration (12 to 18)

**12. When does a chatbot stop being a chatbot and become an agent?**

**[INFERENCE]**

When you decide dynamically the next step, you use tools with effect and itera to the point. A bot that only responds, even with LLM, is chatbot or RAG. The distinction matters because the controls need to follow: whoever performs actions needs delegated identity, scope and HITL.

**13. What differentiates an agent from an automated workflow?**

**[FATO]** **[RECOMMENDATION]**

Who defines the sequence. In workflows, LLMs and tools are orchestrated by predefined code paths; in agents, LLM dynamically drives the process itself and the use of tools. Workflows gain in predictability and testability; agents gain in long tail flexibility. In regulated processes, prefer workflows with LLM steps.

**14. What is the role of MCP in this architecture?**

**[INFERENCE]**

Standard interface between agent and tool catalog, with specified authorisation model. Solve discovery, call schema, OAuth authorization in server access and trace propagation. It does not solve business rule, integration with systems, long processes or events. It requires audience validation and prohibits *token passthrough*. It is recommended to encapsulate the protocol, given the speed of change.

**15. What role does BFF play when agents have tools?**

**[RECOMMENDATION]**

Mold the capabilities for the channel agent: reduce payload and noise, aggregate frequent queries, normalize errors in explicit messages, impose pagination and limits, apply channel policy. BFF does not contain business rule; MCP defines *how* the tool is called, and the BFF, *What?* She gives it back.

**16. When to use API?**

**[INFERENCE]**

When the channel needs immediate response about the current state or wants to command an action whose acceptance can be decided on time. It is the default for most reading tools and commands that initiate processes. Wrong usage sign: long operations solved by synchronous call with high timeouts.

**17. When to use events?**

**[INFERENCE]**

When several consumers react to a fact that has already occurred, the producer should not know them and the reaction may be asynchronous: proactive notifications, reading projections, synchronization between systems, reindication triggers. Wrong usage sign: events used as request and response.

**18. When to use a workflow engine?**

**[RECOMMENDATION]**

When the process has been durable, human stages, timers, compensations or long duration. The agent starts the workflow with idempotence, consults the state and responds to user signals; never keeps the state of the process in the memory itself.

##### 4 · Identity, audit and exceptions (19 to 21)

**19. How to preserve identity and authorization during the execution of the agent?**

**[RECOMMENDATION]** **[FATO]**

Explicit delegation with composite identity, verified in each resource: the user authenticates in the experience; for each tool, the runtime gets a token by *token exchange* (subject = user, actor = agent, clan `act`, minimum scope, specific audience, according to RFC 8693); the tool servers validate the audience and do not pass the token; the final authorization happens at the point of the data; and the “whose” comes from the token, never from parameters generated by the model.

**20. How to audit a decision or action by an agent?**

**[RECOMMENDATION]**

With a task execution record, correlated with the registration system. The audit locates the execution by the transaction protocol, reconstructs the current context (instructions, sources and versions), verifies if the rule came from the domain and was not inferred by the model, confers subject, actor, scope and policy decision, verifies the explicit confirmation and allows the human review provided for in article 20 of the LGPD.

**21. How to deal with human exceptions?**

**[RECOMMENDATION]**

Treating exceptions as first class states of the process: each has type, queue with owner, SLA, structured context transferred and path to return to the flow. Present user confirmations use the interruption of AG-UI; third party approvals, a human task in the workflow engine.

##### 5 · Quality, operation and readiness (22-30)

**22. How to measure DEX when the interface is dynamic?**

**[RECOMMENDATION]**

Measuring by intention, not by screen: resolution by intention, time to resolution, perceived effort, shifts by resolution, editing rate in confirmations, abandonment by step, scaling and motive, recounted in 7 days — combined with the telemetry and feeling of DEX tools.

**23. How to test an interface that changes according to context?**

**[RECOMMENDATION]**

Testing components, contracts and behaviors, instead of fixed screens: components with unit tests, property-based testing and visual regression; all agent output validated against catalog schema; assessments with assertions on AG-UI events issued for each intention; replay of recorded flows with a simulated deterministic agent; accessibility by component and template.

**24. How to test agents?**

**[RECOMMENDATION]**

In layers, with statistical evaluations and regression in IC: tools (contract, idempotence, authorization); tool selection; acceptable trajectory; environment result with simulated systems; safety (red injection teaming, climbing and leakage); regression with thresholds for each model change, prompt or catalog; and continuous sampling evaluation in production.

**25. How to check accessibility in generative IU?**

**[RECOMMENDATION]**

Certifying components, not screens, and controlling dynamics: only audited components (WCAG 2.2 AA) enter the catalog; explicit focus management when the agent inserts or replaces components; moderate `aria-live`, with streaming announced per step; equivalent textual representation of each component; alternative navigation paths.

**26. How to preserve observability in agentic systems?**

**[RECOMMENDATION]**

Three-plan observability (services, agent, quality), with correlated dashes from end to end: OpenTelemetry with GenAI conventions; `traceparent` spread between agent and MCP servers; `RUN events_*` e `STEP_*` as anchors on the experience side; Quality and cost SLOs beyond availability and latency; personal data masked or in restricted storage.

**27. Which components should remain deterministic?**

**[RECOMMENDATION]**

Business rules and eligibility; authorization and policy decisions; execution of actions and their effects, with idempotence; process status; validation of UI entries and props; rendering of each component; components of confirmation, consent and legal notices; audit records; content life cycle (vigency, revocation, disposal).

**28. What components can be adaptive?**

**[RECOMMENDATION]**

Interpretation of intention; explanatory text and tone, within guardrails; choice and order of components within the catalogue and templates; suggestions for next steps; reformulation of search queries; sequence planning in low risk tasks; highlight and pre-fill. The practical rule: **adaptive in interpretation and presentation, deterministic in decision and implementation**.

**29. What capabilities are prerequisites for agents?**

**[RECOMMENDATION]**

Federated identity with delegation (act “in name” with traceability); authorization at the point of the data (the agent cannot be the last barrier); APIs with contract (tools without API have become fragile automation); explicit processes with owner and exception queue; content governed with indexable permissions; catalogue of services and journeys (without it the agent creates a parallel catalogue); observability and execution record; evaluation set (without it, quality is not measurable); AI policy and data classification.

**30. What technologies are really needed and what are only alternatives?**

**[INFERENCE]**

Needed are *capabilities*: identity with delegation, authorization, APIs with contract, durable processes, governed content, search with permission, protocol of interaction agent-IU, ruled generative UI, tool interface, observability and evaluation. AG-UI or own protocol, A2UI, MCP Apps or own schema, MCP or native calls, Elasticsearch or OpenSearch, Temporal or BPMN are alternatives. Micro-frontends, Kafka, service mesh, dedicated vector bank, multi-agent and full MACH **are not requirements**.

Study **[RECOMMENDATION]**

#### Study trails by profile

The common core, for all, is: the problem, the maturity scale, the layer model and the anti-patterns. The learning goal is to be able to explain the difference between the portal it presents and the platform it solves — and why agents depend on foundations. Then each profile follows where your question lives.

##### Corporate or solution architect

**Read:** architecture, integration, flow, decisions.

**Exercise:** choose a real intention and draw the flow through the layers, marking where they stay rule, state, authorization and audit.

##### Product manager

**Read:** EXP, intent experience, roadmap.

**Exercise:** assemble the ranking of the 20 most frequent intentions (the roadmap phase 0 expands to 50) and classify each by volume, risk and viability.

##### UX or designer service

**Read:** intent experience, generative UI, AG-UI.

**Exercise:** specify three agent components (confirmation, progress, fonts) with when to use, props and accessibility requirements.

##### AI Specialist

**Read:** agents and MCP, search and RAG, knowledge, AG-UI.

**Exercise:** build an evaluation set with 30 real questions, reference documents and groundedness criteria.

##### Platform or SRE

**Read:** operation, front end and streaming, integration and resilience.

**Exercise:** set SLIs and SLOs for an intention, including a quality SLO with error budget and the rape runbook.

##### Content

**Read:** governed content, chain of knowledge, search.

**Exercise:** apply the minimum set of metadata to ten normative and identify gaps in validity, owner and permission.

##### Security and compliance

**Read:** identity and governance, agents and MCP, questions 19 to 30.

**Exercise:** classify ten hypothetical tools by risk and define, for each, scope, level of autonomy and HITL rule.

**Integrator exercise for a multidisciplinary group**

1. Choose a journey (e.g. vacation).
2. Each profile analyzes the journey through the lens itself, alone — as in the architectural board.
3. Consolidate in a matrix of responsibilities between roles (the table of twelve lenses serves as a starting point).
4. Identify conflicts and resolve them with trade-off standards.
5. Position the journey in the maturity model and set the next stage of roadmap.


## Frequently Asked Questions

**What is an agent-oriented Digital Workplace?**

It is an intention-oriented corporate portal and agents: instead of organizing links to systems, it receives the employee's request, prepares the action with an agent, requests confirmation and follows the process to the end. The study describes it as the fifth stage of a maturity model that accumulates the previous: no delegated identity, API contracts, governed content and explicit processes, the agent performs actions with too wide credentials and no audit trail.

**What is an EXP and how does it differ from an intranet?**

Employee Experience Platform (EXP) organizes employee services and journeys on registration systems, with identity, context and delivery across multiple channels. The intranet informs and forwards; the EXP executes and follows. The intranet organizes pages and measures reach; EXP organizes journeys, measures resolution and effort and maintains the state of requests. An EXP does not need to be complicable: what the agent requires is that the capabilities are exposed by contract.

**What is the AG-UI protocol?**

AG-UI (Agent User Interaction Protocol) is an interaction protocol between an agent and the application that the user operates, based on event flows: executions, messages, tool calls, shared state, activity and interruptions for human confirmation. It is not a generic UI specification, it does not integrate corporate systems and does not authorize actions. It complements MCP, which connects agent and tools, and A2A, which connects agents to each other.

**Why doesn't RAG replace content governance?**

Because each link in the chain of knowledge inherits the quality of the former and cannot correct it. The RAG recovers the most similar passage, not the current one or the applicable one: without canonical source, duration, owner and permissions in the index, the answer may come out fluent and wrong. The study recommends six blocking requirements before the RAG and, for actions, the rule that the document explains, but the API decides.

**With what identity should a corporate agent act?**

With delegation, not impersonation: a token obtained by token exchange (RFC 8693) in which the subject is the collaborator and the actor is the agent, with minimum scope and specific audience per tool. The tool server validates the audience and does not pass on the received token; the final authorization should happen at the point of the data, and the “whose” comes from the token, never from parameters generated by the model.

**Where to begin the evolution of a portal to this model?**

The study recommends starting with a high-volume and low-risk pilot journey, not the entire company; vacation and called IT are chances of good drivers, not rule. The roadmap has six phases with passing criteria — discovery, minimum foundations, source responses, agent with reading tools, actions with confirmation, expansion by evidence — and seven parallel tracks. Delegated identity and governed content begin in phase 0 because they are usually the critical path.

## Glossary

- **Agentic Digital Workplace** — Corporate portal that solves intentions through an agent, on foundations of identity, knowledge, APIs and processes; fifth stage of the maturity model.
- **Employment Experience Platform (EXP)** — Layer that organizes employee services and journeys on registration systems, with identity, context and delivery in various channels.
- **AG-UI** — Agent-application interaction protocol, based on event flows, shared status and interruptions; it is neither UI nor integration specification.
- **Component Registry** — Contract between agent and design system: catalogue of approved components, with prop schema, effects and accessibility requirements.
- **Permission-aware retrieval** — Recovery where user permission is filtered in the index before the template sees the content.
- **Delegated identity** — Token in which the subject is the user and the actor is the agent (RFC 8693), so that each action is attributable to both; the study recommends limiting it to the intersection of the permissions of both.
- **Human-in-the-loop (HITL)** — Confirmation or formal human decision before an action with effect, registered as an event and with explicit rule of non-execution if not answered.
- **Agent readiness index** — Score from 0 to 20 of a journey in ten criteria; suggests whether it is ready to work foundations, for RAG and reading or for actions with confirmation.

*© 2026 Mauritius Yokoyama Issei. Citable content with assignment (fair use educational).*