Skip to content
Agentic Digital Workplace

Agentic Digital Workplace

From the portal that presents to the platform that solves

Anyone conducting a large corporate portal hears two requests that contradict each other: “Put an AI agent in front of everything” and “first clean the house”. This study shows, layer by layer, what needs to exist before an agent acts on behalf of a employee — and what happens when any of these layers are skipped.

A corporate agent is only as good as the foundations he crosses: intent prioritized, governed knowledge, delegated identity, API contracts and processes explicit. 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, it inherits the failure and cannot Fix it.

Where do you come in? (illustrative questions)

How to read this page

2 minutes

Hero, maturity stages 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 30 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 They precede the agent. If you know the model, jump to the problem: Nothing that comes after depends on watching.

Digital Genetic Workplace: 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 maximum autonomy for sensitive actions stays in the level 2, which obliges 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). View the chain of knowledge.
  • Delegated identity: the agent acts with the identity of the collaborator in minimum scope, not in his place. View 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. View the six-layer architecture.
  • 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: she needs to know where is everything, what is the current rule and in what state is the request itself.

The question that organizes this study is another: what needs to exist for that “Do this for me” be 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.

FACT 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.

FACT
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 employment 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 above: 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 supported only by criteria and criteria. 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. Composite 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. AI-Enhanced Workplace

    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, each step button highlights the column matching matrix below; no 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 unitpageservicejourneyresponseintention solved
Integrationlinkspoint to pointcontractscontracts + indexcontracts + tools + delegation
Contentpagespages + catalogheadlessgoverned and indexed with ACLgoverned, indexed and used for action
IdentityloginSSOSSO + profileSSO + Index permissionssubject delegation + actor
Caseoutside the portalformsworkflowsworkflows with LLM stepsagent as process interface
UXmenuscatalogjourneysnatural languageintention + adaptive IU
OperationavailabilityavailabilitySLOs per capacity+ quality of responses+ Agent Traces, Cost, Quality Error Budget
GovernanceeditorialcatalogcontractsAI and dataautonomy 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 advance in parallel by trails — initiate content governance of E4 while building the E3 APIs — but the study does not recommend operating the E5 without previous capacities within the scope of qualified intentions. Hence the maturity is evaluated per journey, not by the entire portal: an organization may be in the 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.
StageCapabilitiesMain risksOrganisation
1 · Intranetintranet CMS, link directory, news, simple searchoutdated content; collaborator as “human integration”internal communication portal owner
2 · Digital WorkplaceSSO, service catalogue, audiences, self-service in some domains, mobile app, call openingcatalog that is just a list of links; superficial customizationemployee digital product begins to exist; domains provide services
3 · Composite EXPDomain APIs with contract; headless content; cross-domain journeys; multichannel system design; workflow for long processesmicroservices and micro-frontends without need; BFF turning monolithdomains such as capabilities owners; platform team; journey owner
4 · AI-Enhancedhybrid search with permissions; RAG with citations; copilots in specific tasks; workflows with LLM stepsRAG on ungoverned content; oversharing leakage; hallucinationowners of content with curated time; AI committee; AI platform team
5 · Agenticagent with reading and writing tools; delegated identity; Formal HITL; regulated generative UI; interaction protocol; execution recordexcess agency; agent-ESB; rules in the prompt; quiet incidents of quality; instability of protocolstool 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 to position decisions, find dependencies and talk between disciplines. Each layer has a responsibility and, as important as, what no It's her responsibility. The bottom layers (integration, knowledge, identity) are prerequisite of the top (agent, generativa UI).

Collaborator — intent, navigation, confirmation

Experience Layer web, mobile, collaboration channels, notifications, generative UI, client AG-UI
Experience Layer
Is responsible forYou are not responsible for
render approved components on any channeldecide business rules
capture intent, confirmations and editionscall registration systems directly
accessibility and visual consistencystore 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 forYou are not responsible for
interpret intention and planbe the source of the truth of any given
choose allowed catalog toolscontain eligibility rules
conduct confirmations and interruptionsmaintain long-term processes
explain results with sourcesdecide permissions
record execution (trace)integrate point-to-point registration systems

service and day consultation · tools (MCP)

Employment Experience Platform (EXP) catalog of services, journeys, profile and context, customization, status of requests
Employee Experience Platform
Is responsible forYou are not responsible for
catalogue of services and their display rulesexecute domain business rule
definition of journeys, including cross-domaininterpret natural language
profile and context of the collaborator, with legal basisbe 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 forYou are not responsible for
canonical content with metadata, validity, owner and permissionsgenerate answers
Hybrid index with synchronized ACLsdecide, 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 forYou are not responsible for
expose domain capabilities by contractcontain 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, legacy

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 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.
LayerDecisionAlternatives
ExperienceSaaS platform own shell or extensionmodular monolith, micro-frontends, server or border composition
ExperienceGenerative UI specificationA2UI, MCP Apps, Open-JSON-UI, own schema
Agentplatform agent or independentsee paradox in Decisions
Agentan agent or multi-agent; where the model runssingle agent with filtered catalog; managed, private or local cloud
EXPbuild, buy or use the existing suitedepends on the inventory
Knowledgesearch engineElasticsearch, OpenSearch, managed service
IntegrationDirect MCP to domains or via BFFservers Fine MCP calling BFF and APIs
Transversalmodel authorisationRBAC, 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 include it in the health plan.” The request is a good test because it brings together intention with emotional burden, sensitive personal data, eligibility rule with deadline, collection of document, action with effect, asynchronous process with possible human analysis and a longer journey (license, leaf) 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 dependent form Agent → Interface Frontend tool: Who defines the catalog is the application, not the agent.
  7. STATE_DELTA Agent ↔ Interface Atomic patch JSON: applies whole or is rejected, with snapshot resynchronization. The attachment goes to a document repository; the agent receives only the reference.
  8. RUN_FINISHED · interruption confirmacao_acao 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 of editing 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 FACT according to AG-UI 1.0 specification.

What AG-UI is — and what is not

FACT O AG-UI (Agent User Interaction Protocol) it is a protocol to connect user-oriented applications to agents, by flow of events. 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 among themselves; AG-UI connects the agent to the user.

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

The eight families of AG-UI events
Specification 1.0. FACT as to events; the column of use is INFERENCE.
FamilyEventsUse in a Digital Workplace
Runs and stepsRUN_STARTED, RUN_FINISHED, RUN_ERROR, STEP_STARTED, STEP_FINISHEDlife cycle of a request; basis for latency metrics
Text messagesTEXT_MESSAGE_*conversational response on streaming
Tool callsTOOL_CALL_*proposed action; arguments come in fragments
ReasoningREASONING_*visibility of reasoning, with encrypted artifacts
StatusSTATE_SNAPSHOT, STATE_DELTA, MESSAGES_SNAPSHOTshared status, such as draft of a request
ActivityACTIVITY_SNAPSHOT, ACTIVITY_DELTAstructured progress outside transcription (“checking eligibility...”)
SubagentsSUBAGENT_STARTED, SUBAGENT_FINISHED, SUBAGENT_ERRORoutput assignment to subagents
PassthroughRAW, CUSTOMescape for proprietary events; in excess, loses interoperability
State, interruptions and transport
  • FACT 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.
  • FACT An execution that needs external input ends with RUN_FINISHED carrying an interruption (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.
  • FACT 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
DifferenceImpact
The collaborator is in a collaboration toolthe same agent and status; the component renders as card; the attachment may require link to the app
The benefits system is out of the aircircuit 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 daughterthe tool solves “dependent” by the identity of the requester and does not accept arbitrary text IDs
An indexed document contains malicious instructionthe recovered content is treated as given; guardrails and the absence of dangerous tools limit the impact of

In the vertical of agents, the same design — agent cycle, fail-closed, HITL — is detailed AI Agent Engineering.

Technical pillars

The eight pillars under architecture

Each pillar answers a question the agent alone does not answer. Cards summarize the main finding; the deepening of each is collected. The same criterion for everyone: what exists, what is missing and what is not responsibility his.

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
SizeModern IntranetEXP
Unitpage and sectionjourney and service
Systemslink or embedAPI; action within the experience
Backgroundhearing (area, location)profile, moment of life, state of requests
Channelweb, mainlyweb, mobile, collaboration, notifications
Successvisits, reachresolution, time to resolution, effort
Ownerinternal communicationproduct, 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.

FACT 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: resources ui:// pre-declared, 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.

FACT 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 agentContent capacity
cite the current versionduration (start and end) and status
do not reveal restricted contentexplicit and exportable permissions to the index
answer to the right audienceapplicability metadata (load, area, region, link)
understand synonymscontrolled taxonomy
knowing who corrects a wrong answerowner and revision cycle
recover the right snippetstructured content in sections, with titles and hierarchy
delete when the law commandsILM and retention propagated to index and logs
RECOMMENDATION

5 · Integration: gateway, BFF, events and workflows

The agent needs to contractsNot 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
CriteriaSynchronous APIEventsWorkflow engine
Interactionimmediate question and answerfact already occurredsteps over time
Consumersoneseverala process
Durationms to secondscontinuousminutes to months
Wrong usage signtimeouts in long operationsevents used as request-responseengine 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.

FACT 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
TechniqueStrong inWeak in
Lexical (BM25)acronyms, normative codes, names, numberssynonyms and paraphrases
Dense semanticsquestions in natural languagerare terms, denial, exact numbers
Hybridrobustnesscalibration and evaluation
Rerankingaccuracy in the first resultslatency and cost
Knowledge graphrelational and global questionsconstruction 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
  • FACT 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”.
  • FACT 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.
FACT

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 events CUSTOM.
  • INFERENCE Emerging maturity, in consolidation: suitable for pilots with encapsulation; premature as non-encapsulated long-term dependence.

Detail in Flow tip to tip.

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. RAG does not correct a wrong permission in ECM; the agent does not correct an absent term CMS. So the RAG is the last link, not the first: before it there is canonical source, metadata, permissions and index.

  1. 1 · ECMKeep 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 · CSPIt exposes this content as services for various applications. “How do other applications access governed content?”
  4. 3 · HeadlessStructures 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 · SearchFind 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 · RAGIt generates an answer based on the excerpts found. “How to respond in natural language without inventing?”
  9. 6 · AgentUse 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 pass between 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
StepFunctionQuality control
Capturereceive publication and change eventsno content enters without traceable event
Extractiontext, structure, tables; OCR when neededRegistered OCR trust
Standardisationcleanliness, language, title standardization—
SegmentationChunks by structure, with title and section pathverified size and consistency
Enrichmentinherited metadata, entities, synonymsmandatory metadata present
Vectorizationmodel versioned embeddingsregistered model version
Indexhybrid index with ACLs and metadataleak test after each load
Removalwithdrawal and discard propagatedPropagating 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
UsageExampleRequest
Reply“What is the rule of teleworking?”RAG with citation and duration
Decide what to do“my daughter was born” triggers the day of birthcatalogue of services and journeys (EXP), not only documents
Grounding an actionexplain why inclusion has a deadlinethe 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 subject of Knowledge OS Enterprise.

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 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 FACT

RFC 8693 distinguishes both cases. In impersonation, A “is indistinguishable from B”. Na delegation, A maintains its own identity and is explicit that acts representing B: a clan act identifies the actor, and who consumes the token considers the subject and the Actor when applying politics. 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” becomes the sub token, 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.
LevelExampleControlCeiling for sensitive actions
0 Informsresponds with sourcesnoneinside the ceiling
1 Suggestsproposes the action and prepares the formuser executesinside the ceiling
2 Run with confirmationsummarizes and asks “confirm”HITL interruptioninside 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 notifieslow risk reverse actionsundo available; auditabove the ceiling
4 Execute without humanvery low risk routinesexplicit policy; monitoringabove 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
ClassExampleRule
Own data readinghour balanceallowed with delegate token
Reversible writingrequest draftpermitted; notify
Written with effectsubject vacation, include dependentexplicit confirmation (interruption)
Financial, legal or access effectchange bank account, grant accessconfirmation + strong reset; possibly third-party approval
In the name of another personmanager approvingonly with verified role and specific policy
Forbidden on Agent Channelwithdrawal, wage changenot 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 FACT. 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
ThreatDescriptionMitigations
Direct prompt injectionuser tries to make agent ignore rulesguardrails; authorization does not depend on prompt
Indirect injectionindexed document or tool response contains instructionscontent treated as data; limited tools; separate instruction and data channels
Agency excessfunctionality, permission or autonomy (OWASP LLM06)minimum catalogue; scopes; HITL
Confused warehousethe agent uses its authority for what the user could notdelegation with permissions intersection
Token passthroughserver passes token without validating audienceprohibited by MCP; token exchange
Exfiltration by exitsensitive data in response or URLmasking; domain allowlist; no arbitrary links
SSRF via discoveryOAuth metadata pointing to internal addressesURL validation; private track blocking; exit proxy
Secrets in Contextkeys in prompts or logssecret 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
ClassDoes it fit into the context of the model?Does it appear in the answer?Detention in logs
Public or internalYesYesdefault
Common staffYes, the holder himselfyes, to the holder himselfshort
Sensitive personnel (LGPD, Art. 5, II)only the minimum, with registered purposesummary to the holder himselfminimum or masked
Business confidentialityno, except authorised toolnoaccording to policy
Secretsnevernevernever

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 FACT.

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 of Trust Engineering.

Cases RECOMMENDATION

The agent within the process, and the human exceptions

The agent is a intelligent interface on explicit processes, not a Substitute for them. Corporate processes accumulate three types of knowledge: rule explicit (“dependent up to 21 years, or 24 if student”), tacit rule (“in practice, HR accept the school statement by the end of the month”) and trial (“I will consult the legal”). The agent tends to handle the first one well. In front 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.

So the architecture separates four responsibilities, each with owner and testing own: interaction (agent understands, collects, explains, confirms and accompanying), orchestration (workflow: state, steps, timers, tasks human, compensation), decision (area: eligibility, calculations, validations) and log (registration system). The agent may switch from model 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.

FACT For confirmation of its own user, 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 a approval can take days. The SLA belongs to Case, not the agent — the agent informs the deadline, does not create it.

The agent also works as process sensor INFERENCE: the questions he does not solves and the forwarding exceptions reveal ambiguous rules, API gaps and steps Unnecessary. This feedback is a useful byproduct of the age layer — provided that There is a owner to receive it.

What the agent does and doesn't do at every stage
Nine stages of the process
StepThe agent does.The agent doesn't.Mechanism
Triggeracknowledges the intention and identifies the processinvent a non-existent processEXP service catalogue
Preconditionsconsultation eligibilitydecide eligibilityRule API
Collectionpre-fill with system data; asks only what is missinginfer critical datastructured components, state AG-UI
Validationclearly shows errorsignore validationsfield validation
Submissionbegins the process with idempotence, after confirmationsubmit actions with no confirmationinterruption AG-UI + tool
Approvalnotifies and summarizes the context for the approveerapprove on behalf of the approveerhuman task in workflow
Exceptiondetects, explains and forwards with contextresolve the exception aloneexception queue
Monitoringconsults the state and explainspromise deadlines outside the SLAWorkflow Status API
Closureconfirms the result and offers next stepsdeclare completed what was only acceptedcompletion 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
CaseVolumeVariabilityRiskSuggested approach
Consultation of holiday balance or hourshighlowlowread tool; direct response
Request for a holidayhighlowmediumInitiating agent + confirmation
Open call for IThighhighlowscreening agent (LLM step) and opening
Inclusion of dependentsmediummediumhigh (sensitive data)initiator agent + document + workflow with validation
Request for accesshighmediumhighagent collects and justifies; mandatory human approval
Onboardingmediummediummediumorchestrated workflow; agent as guide
Change of postlowhighhighsystemic workflow; agent only informs
ShutdownlowhighToo highhuman 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" with moderation; streaming announced per 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 Council of architecture analyzes the journey by each lens separately before consolidate; conflicts resolve with the standards 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.
PaperYou ask what only he doesIf ignored
Enterprise ArchitectWhat business capabilities does the platform expose and who owns each one?agent becomes improvised integrator
Integration ArchitectAPI, event or workflow for each interaction?coupling and inconsistent states
Product StrategistWhat intentions are worth more and how do we measure resolution?technology looking for trouble
Process / BPMIs the rule explicit, with owner and exception line?Inconsistency automation
UX ArchitectHow does the collaborator trust, confirm and resume?actions without clear consent
Front-end ArchitectHow to compose dynamic UI without breaking the design system?Arbitrary, inaccessible IU
AI ArchitectWhat agent, with what tools and what evaluation?hallucination and excess agency
Content StrategistWhat is the canonical source, duration and owner?RAG on content without governance
Search ArchitectDoes the search respect permissions in the index?oversharing leak
Security / IAMWith what identity does the agent act and with what scope?generic service account
Date & AI GovernanceLegal basis, retention, inventory of use cases?non-compliance with LGPD
SRE / PlatformHow 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 you choose is the mechanism that balances them. Each card says what It'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 FACT.

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 Critical

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 like 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 High

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 High

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; absence of component catalogue.
Alternative
declarative composition on approved catalog, or IU isolated in sandbox, with props validation.
07 Medium

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 Medium

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.
09 Medium

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 Medium

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 Medium

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 Medium

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 Medium

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 Medium

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.

Technological 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 delegationany IdP with OAuth 2.x and token exchange or equivalent mechanism
Authorization at data pointRBAC + ABAC, ReBAC, OPA or Cedar engines, rules in the registration system itself
Contract APIs for used capabilitiesREST, GraphQL, gRPC; via gateway and BFF or directly
Durable processes with human stagesTemporal, BPMN engines, native SaaS system or platform workflow
Content with metadata, duration and permissionsECM/CSP, CMS headless, productivity platforms
Hybrid search with permission filtersElasticsearch, OpenSearch, managed services, combinations
Interaction protocol agent ↔ IUAG-UI, own protocol, SaaS platform features
Generating IU governedA2UI, MCP Apps, Open-JSON-UI, own design system schema
Standard tool interfaceMCP, native framework function calls, direct integration
End-to-end observationOpenTelemetry with any compatible backend
Continuous assessmentvarious 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. In a Agent-oriented platform it may be available, fast and wrong: responding with a revoked policy, 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.

FACT OpenTelemetry maintains conventions semantics for GenAI (still evolving), and MCP review 2026-07-28 documents the spread of traceparent between agent and tool server. Events RUN_* and STEP_* AG-UI delimit executions and serve as anchor for spans on the experience side INFERENCE. Personal data in traces: prompts and full answers go to restricted storage and short restraint, or are masked.

SLOs that include quality and cost

Examples of objective, calibrating by intention RECOMMENDATION
FamilyIndicator (SLI)Example of objective
Availabilityexecutions without RUN_ERROR by platform failure≥ 99,5%
Latencytime to the first tokenp95 < 1.5 s
Latencyshift with up to 2 toolsp95 < 8 s
Qualityknowledge responses supported by sources (sample)≥ 95%
Qualitypermission leakage in continuous tests0
Valuehumanless resolution in the intentions empowered≥ baseline per intention
Costcost per resolved intention≤ budget per intention

When quality error budget — for example, groundedness below the goal for two weeks —, prompt, model and model changes Tool catalog is frozen until correction. It's the same discipline that already exists for availability, applied to quality.

INFERENCE An agent who binds tools inherits availability combined 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
CategoryMetricWhy Does It Matter
Latencytime to the first token; full shift; by tool; modeluser perception and diagnosis of bottleneck
Costtokens per turn, conversation and resolved intention; cost per modelbudget and loop detection
Toolserror rate, timeouts, relays, open circuitshealth of dependencies
Agentsteps per task, replanning, tasks that reach the limit of stepsefficiency and loops
Retrievalempty results, average score, distribution of sources, age of content citedquality of knowledge
Securitypolicy denials, injection detections, abandoned interruptionsrisk posture
Qualitysampling groundness, evaluated correction, negative feedback by reasonperceived quality
Experienceresolution by intention, scaling, recount, abandonmentvalue 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
TypeExampleDetection
Availabilitymodel provider outerror metrics
Latencyslow system drops shiftstool latency
Qualityreindexion broke the chunking; answers without sourcecontinuous evaluation, feedback
Securityrestricted content leakcontinuous tests of permission, reports
Costtool loop multiplies tokenscost alerts per conversation
Behaviorthe agent started to perform action without confirmation after changing the promptregression 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.

Roadmap RECOMMENDATION

Six phases, seven trails and a critical path

Phases have passing criterion; tracks advance in parallel and rhythms different. 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 slower dependencies, because they involve IdP suppliers, legacy systems and owners content 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 authorisationcritical pathSecurity / IAM 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 · Experience
UX / 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 agents
AI Architect
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, buttons faint other lines (continue in 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
CriteriaWeightWhy?
Volume of intentionshighperceptible value
Low risk of actionhighsafety in learning
Available APIshighviability
Governable contentmediumquality of responses
Engaged process ownerhighreceives feedback and solves exceptions
Low data sensitivitymediumreduces 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
RiskMitigation
“Invisible” foundations lose sponsorshipearly deliver improved search (phase 2) as visible value
Pressure for jumping to stockexplicit and agreed pass criteria with sponsors
Change of protocol specificationinternal adapters; contract tests
Supplier of a SaaS platform launches own agent during the programexplicit decision agent of the platform × independent, revisited at each stage
Central Team Dependencypaved paths and distributed tool property
Main metrics per phase
PhaseMetrics
0inventory coverage; defined baseline
1% of pilot content with mandatory metadata; SLO APIs
2recall@k, groundedness, leaks (zero), resolution
3turn latency, tool error, cost per conversation
4action errors, editing rate, exceptions solved in SLA, satisfaction
5intent 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. Calculation happens in your browser: nothing is sent and nothing is guarded.

Unanswered criterion counts as absent (0).

Intent prioritized with baseline
Explicit process with owner
Contract APIs
Delegated identity
Content governed
Permission search
Components in the catalogue
Assessment set
Observability and audit
Governance approval

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
    TotalReading
    0 to 9little ready for AI: working foundations
    10 to 15ready for RAG and read tools if listed gaps are not blocked
    16 to 20candidate 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 begin to import RECOMMENDATION
    SizeMetricHow to measureStage
    Producthuman-free resolution by intentiontelemetry + recount2
    Producttime to resolutionfrom request to result in registration system2
    Productperceived effortshort post-interaction search2
    Integration% of priority capabilities with API and versioned contractcatalog3
    Integration% of capabilities with published SLOcatalog3
    Case% of priority processes with owner, explicit rule and queueinventory3
    Content% of content indexed with duration, owner and permissionmetadata validation4
    Contenttime of revocation of the indexevents4
    Searchrecall@k and nDCG in the evaluation setevaluation4
    Searchleaks in permission tests (meta: zero)continuous tests4
    AIsample groundnessevaluation4
    AIaccuracy of tool selectionevaluation5
    Security% of tools with delegated token and minimum scopecatalog5
    Security% of shares with registered confirmationaudit5
    UX% of agent screens composed of catalogue components onlyrendering telemetry5
    UXEditing fee in confirmationstelemetry5
    Operation% of executions with trace end to endobservability4
    Operationcompliance with quality SLOspanel5
    Costcost per resolved intentionobservability4
    Governance% of AI use in approved inventoryinventory4

    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 subject of 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 it It matters; 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?

    FACT

    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?

    FACT

    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?

    FACT 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?

    FACT 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 FACT

    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 on the token; the final authorization happens at the point of the data; and the “whom” 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 catalogue; explicit focus management when the agent inserts or replaces components; aria-live moderate, with streaming announced per step; textual representation equivalent of each component; alternative paths by navigation.

    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; spread of traceparent between agent and MCP servers; events RUN_* and 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 everyone is: the problem, the maturity scale, the model of layers and the anti-patterns. The learning goal is to explain the difference between the portal it presents and the platform it solves — and by that 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, experience by intention, 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.

    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 responsibilities matrix between roles (the twelve lenses serves as a starting point).
    4. Identify conflicts and resolve them with the standards of trade-offs.
    5. Position the journey in maturity model and define the next phase of roadmap.

    In short

    Agentic Digital Workplace, in Few Lines

    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.

    It is the same principle of autonomy proportional to the evidence of Trust Engineering, applied to the corporate portal.

    Frequently Asked Questions

    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.