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.
Agentic Digital Workplace
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
Where do you come in? (illustrative questions)
Phases with passing criteria and parallel trails; identity and content are the critical path.
Go to roadmap → “Our RAG responds wrong or shows what it should not.”The RAG is the last link of a chain; before it there is canonical source, metadata and permissions.
See the chain of knowledge → “ With what identity will the agent act?”Delegation, non-impersonation: subject, actor, minimum scope and authorization at the point of the data.
See identity and autonomy → “ At what stage is our portal?”Ten criteria, score from 0 to 20 per day, calculated in your browser.
Calculate readiness →Hero, maturity stages and the block In short. You go out with the five-stage model and the thesis.
Add architecture, flow, trust and roadmap.
The whole page, with the collectible deepenings and 30 critical questions.
Video summary RECOMMENDATION
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.
Skip the video and continue reading ↓
Support text, not an integral transcript of the video.
The Problem INFERENCE
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?
Each domain has its own experience, language and queue. The sum of these maps is what the collaborator carries on his head.
Asking in natural language and receiving a source response has become a common expectation in consumer tools and tends to be taken to work.
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.
Every block derived from the study carries a stamp. The label is text; the color is not the only carrier.
Maturity RECOMMENDATION
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.
Content + Links + Systems
Content + Services + Customization
APIs + Headless + Days + Micro-frontends
Search + RAG + Copilots + Automation
Intent → Agent → Knowledge → Tools → Process → Dynamic experience
| Size | E1 · Intranet | E2 · Digital Workplace | E3 · Composite EXP | E4 · AI-Enhanced | E5 · Agentic |
|---|---|---|---|---|---|
| Value unit | page | service | journey | response | intention solved |
| Integration | links | point to point | contracts | contracts + index | contracts + tools + delegation |
| Content | pages | pages + catalog | headless | governed and indexed with ACL | governed, indexed and used for action |
| Identity | login | SSO | SSO + profile | SSO + Index permissions | subject delegation + actor |
| Case | outside the portal | forms | workflows | workflows with LLM steps | agent as process interface |
| UX | menus | catalog | journeys | natural language | intention + adaptive IU |
| Operation | availability | availability | SLOs per capacity | + quality of responses | + Agent Traces, Cost, Quality Error Budget |
| Governance | editorial | catalog | contracts | AI and data | autonomy and audit |
The RAG works for questions, but there are no APIs to act on: the “agent” only responds.
Agent with improvised integrations, broad credentials and ungoverned knowledge. High risk of incident.
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.
To be in an internship, the organization meets the all His criteria. Stage 1 has no entry criteria.
| Stage | Capabilities | Main risks | Organisation |
|---|---|---|---|
| 1 · Intranet | intranet CMS, link directory, news, simple search | outdated content; collaborator as “human integration” | internal communication portal owner |
| 2 · Digital Workplace | SSO, service catalogue, audiences, self-service in some domains, mobile app, call opening | catalog that is just a list of links; superficial customization | employee digital product begins to exist; domains provide services |
| 3 · Composite EXP | Domain APIs with contract; headless content; cross-domain journeys; multichannel system design; workflow for long processes | microservices and micro-frontends without need; BFF turning monolith | domains such as capabilities owners; platform team; journey owner |
| 4 · AI-Enhanced | hybrid search with permissions; RAG with citations; copilots in specific tasks; workflows with LLM steps | RAG on ungoverned content; oversharing leakage; hallucination | owners of content with curated time; AI committee; AI platform team |
| 5 · Agentic | agent with reading and writing tools; delegated identity; Formal HITL; regulated generative UI; interaction protocol; execution record | excess agency; agent-ESB; rules in the prompt; quiet incidents of quality; instability of protocols | tool and permission forum; process owners receiving agent feedback; Quality SRE |
“Micro-frontends” in stage 3 formula indicates modularity of experience, not the obligation to adopt them in runtime.
Reference architecture RECOMMENDATION
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
| Is responsible for | You are not responsible for |
|---|---|
| render approved components on any channel | decide business rules |
| capture intent, confirmations and editions | call registration systems directly |
| accessibility and visual consistency | store state of process |
| maintain the AG-UI connection and apply status (snapshots, deltas) | authorize actions (just reflects what the backend allows) |
AG-UI (events, state, interruptions)
| Is responsible for | You are not responsible for |
|---|---|
| interpret intention and plan | be the source of the truth of any given |
| choose allowed catalog tools | contain eligibility rules |
| conduct confirmations and interruptions | maintain long-term processes |
| explain results with sources | decide permissions |
| record execution (trace) | integrate point-to-point registration systems |
service and day consultation · tools (MCP)
| Is responsible for | You are not responsible for |
|---|---|
| catalogue of services and their display rules | execute domain business rule |
| definition of journeys, including cross-domain | interpret natural language |
| profile and context of the collaborator, with legal basis | be the normative content repository |
| aggregated status of requests and notifications |
INFERENCE EXP allows the traditional agent and navigation to offer the same services, with the same display rules. Without it, the agent creates a parallel catalogue.
| Is responsible for | You are not responsible for |
|---|---|
| canonical content with metadata, validity, owner and permissions | generate answers |
| Hybrid index with synchronized ACLs | decide, in the generation, what the user can see |
| retrieval with filters and reranking; high value entity graph |
| Is responsible for | You are not responsible for |
|---|---|
| expose domain capabilities by contract | contain business rules |
| BFF adapted to agent channel; durable processes (workflow) | interpret intentions |
| distribute reading events and projections; resilience (timeouts, circuit breakers, idempotence) |
Contract APIs
Source of truth and rule. Change slowly; architecture must protect them. the load and call patterns introduced by agents (rate limit, cache, reading projections).
| Layer | Decision | Alternatives |
|---|---|---|
| Experience | SaaS platform own shell or extension | modular monolith, micro-frontends, server or border composition |
| Experience | Generative UI specification | A2UI, MCP Apps, Open-JSON-UI, own schema |
| Agent | platform agent or independent | see paradox in Decisions |
| Agent | an agent or multi-agent; where the model runs | single agent with filtered catalog; managed, private or local cloud |
| EXP | build, buy or use the existing suite | depends on the inventory |
| Knowledge | search engine | Elasticsearch, OpenSearch, managed service |
| Integration | Direct MCP to domains or via BFF | servers Fine MCP calling BFF and APIs |
| Transversal | model authorisation | RBAC, ABAC, ReBAC or combination |
Flow tip to tip RECOMMENDATION
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.
RUN_STARTED
Agent → Interface
Start of execution and creation of trace with correlation ID.
ACTIVITY_SNAPSHOT
Agent → Interface
Transparent progress; the screen reader receives a moderate ad.
TOOL_CALL_START · eligibility
Agent → Tools (token delegate: subject + actor)
The staff member receives “eligible, deadline, required documents”; does not decide eligibility.
TOOL_CALL_START · render dependent form
Agent → Interface
Frontend tool: Who defines the catalog is the application, not the agent.
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.
RUN_FINISHED · interruption confirmacao_acao
Agent → Interface
“A interrupted execution is a finished execution”: the answer comes in a new execution.
TOOL_CALL_START · start include
Agent → Tools → Workflow
Repeat call does not duplicate inclusion; process status lives in workflow engine.
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.
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.
| Family | Events | Use in a Digital Workplace |
|---|---|---|
| Runs and steps | RUN_STARTED, RUN_FINISHED, RUN_ERROR, STEP_STARTED, STEP_FINISHED | life cycle of a request; basis for latency metrics |
| Text messages | TEXT_MESSAGE_* | conversational response on streaming |
| Tool calls | TOOL_CALL_* | proposed action; arguments come in fragments |
| Reasoning | REASONING_* | visibility of reasoning, with encrypted artifacts |
| Status | STATE_SNAPSHOT, STATE_DELTA, MESSAGES_SNAPSHOT | shared status, such as draft of a request |
| Activity | ACTIVITY_SNAPSHOT, ACTIVITY_DELTA | structured progress outside transcription (“checking eligibility...”) |
| Subagents | SUBAGENT_STARTED, SUBAGENT_FINISHED, SUBAGENT_ERROR | output assignment to subagents |
| Passthrough | RAW, CUSTOM | escape for proprietary events; in excess, loses interoperability |
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.| Difference | Impact |
|---|---|
| The collaborator is in a collaboration tool | the same agent and status; the component renders as card; the attachment may require link to the app |
| The benefits system is out of the air | circuit breaker open; agent explains, saves draft and offers reminder or call |
| Politics changed yesterday. | the index reflects the new version per life cycle event; the responses cite the new version of the index. |
| Ask for someone else's daughter | the tool solves “dependent” by the identity of the requester and does not accept arbitrary text IDs |
| An indexed document contains malicious instruction | the recovered content is treated as given; guardrails and the absence of dangerous tools limit the impact of |
In the vertical of agents, the same design — agent cycle, fail-closed, HITL — is detailed AI Agent Engineering.
Technical pillars
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.
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.
| Size | Modern Intranet | EXP |
|---|---|---|
| Unit | page and section | journey and service |
| Systems | link or embed | API; action within the experience |
| Background | hearing (area, location) | profile, moment of life, state of requests |
| Channel | web, mainly | web, mobile, collaboration, notifications |
| Success | visits, reach | resolution, time to resolution, effort |
| Owner | internal communication | product, with domains such as service providers |
An EXP does not need to be componsible: for agents, the real requirement is that capabilities are exposed by contract. MACH is a possible strategy, not a requirement; MACH Alliance is an association of suppliers, and its material is market positioning INFERENCE. API-first and headless are for agents; microservices only where there is organizational border.
Micro-frontends solve a problem organization (deploy independent teams), not technical. Without the measured need, a modular monolith usually serves the same purpose INFERENCE.
Only if the three conditions are true:
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.
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.
ui:// pre-declared, rendered in isolated iframes; proposal November 2025.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.
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.
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.
| Request of the agent | Content capacity |
|---|---|
| cite the current version | duration (start and end) and status |
| do not reveal restricted content | explicit and exportable permissions to the index |
| answer to the right audience | applicability metadata (load, area, region, link) |
| understand synonyms | controlled taxonomy |
| knowing who corrects a wrong answer | owner and revision cycle |
| recover the right snippet | structured content in sections, with titles and hierarchy |
| delete when the law commands | ILM and retention propagated to index and logs |
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.
| Criteria | Synchronous API | Events | Workflow engine |
|---|---|---|---|
| Interaction | immediate question and answer | fact already occurred | steps over time |
| Consumers | one | several | a process |
| Duration | ms to seconds | continuous | minutes to months |
| Wrong usage sign | timeouts in long operations | events used as request-response | engine for a simple call |
The agent's BFF reduces payload and noise (tokens cost and confuse), aggregates frequent queries, normalizes errors in explicable messages, imposes pagination and applies the agent channel specific policy. Legacy without events can use CDC; transactional outbox avoids “state changed, event lost”. The agent start the workflow with idempotence key, consultation the state and responds human signs — never keeps the state in its own memory.
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.
| Technique | Strong in | Weak in |
|---|---|---|
| Lexical (BM25) | acronyms, normative codes, names, numbers | synonyms and paraphrases |
| Dense semantics | questions in natural language | rare terms, denial, exact numbers |
| Hybrid | robustness | calibration and evaluation |
| Reranking | accuracy in the first results | latency and cost |
| Knowledge graph | relational and global questions | construction and maintenance |
The merging of lists by RRF (Reciprocal Rank Fusion) combines results by post without normalizing scores. The RAG was formalized by Lewis et al. (2020). O Agent RAG wins in composite questions (political + personal data) and loses in predictability, latency and cost; for simple policy questions, the classic RAG tends to be more appropriate. Models make worse use of information in the middle of long contexts (Liu et al., 2023): fewer excerpts, more relevant. Assessment by layer: recovery (recall@k, nDCG), permission (empty should be zero), grounding, correction and utility.
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.
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.
CUSTOM.Detail in Flow tip to tip.
Knowledge INFERENCE
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.
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.
Status and duration (vigid, revoked, beginning and end) in all normative content; explicit and exportable permissions, synchronized with the index.
Real questions with reference answers, measured recall and leak test with low privilege identities after each index load.
Without it, do not implement RAG in production.
| Step | Function | Quality control |
|---|---|---|
| Capture | receive publication and change events | no content enters without traceable event |
| Extraction | text, structure, tables; OCR when needed | Registered OCR trust |
| Standardisation | cleanliness, language, title standardization | — |
| Segmentation | Chunks by structure, with title and section path | verified size and consistency |
| Enrichment | inherited metadata, entities, synonyms | mandatory metadata present |
| Vectorization | model versioned embeddings | registered model version |
| Index | hybrid index with ACLs and metadata | leak test after each load |
| Removal | withdrawal and discard propagated | Propagating SLO |
Permission-aware retrieval in five steps: permissions as metadata of each chunk, inherited from the origin; prefilter in the index, with the identity solved by the idP and never after of the model see the content; event-oriented synchronization, with SLO; continuous leak tests with low privilege identities; overshare review before indexing.
| Usage | Example | Request |
|---|---|---|
| Reply | “What is the rule of teleworking?” | RAG with citation and duration |
| Decide what to do | “my daughter was born” triggers the day of birth | catalogue of services and journeys (EXP), not only documents |
| Grounding an action | explain why inclusion has a deadline | the rule comes from the domain (API); the document only explains |
RECOMMENDATION Never use the text of a recovered document as a rule source to execute an action: the document explains; the API decides. Transactional data goes by tool; structured content, by Content API; normative content, by RAG with filters; relationships, by graph or domain API; tacit knowledge no use — it is explained first or referred to a person.
Knowledge as a governed infrastructure, not as a passive repository, is the subject of Knowledge OS Enterprise.
Identity, autonomy and governance RECOMMENDATION
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.
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.
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.
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.
| Level | Example | Control | Ceiling for sensitive actions |
|---|---|---|---|
| 0 Informs | responds with sources | none | inside the ceiling |
| 1 Suggests | proposes the action and prepares the form | user executes | inside the ceiling |
| 2 Run with confirmation | summarizes and asks “confirm” | HITL interruption | inside the ceiling (limit) |
| Recommended ceiling for sensitive actions: financial, legal or sensitive data in regulated sector remain at level 2, at most, until there is accumulated evidence of security. | |||
| 3 Executes and notifies | low risk reverse actions | undo available; audit | above the ceiling |
| 4 Execute without human | very low risk routines | explicit policy; monitoring | above the ceiling |
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.
The user, by delegation (subject + actor), with specific audience by tool and minimum scope.
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.
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.
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.
With an immutable execution log per task, correlated to the log of the registration systems.
| Class | Example | Rule |
|---|---|---|
| Own data reading | hour balance | allowed with delegate token |
| Reversible writing | request draft | permitted; notify |
| Written with effect | subject vacation, include dependent | explicit confirmation (interruption) |
| Financial, legal or access effect | change bank account, grant access | confirmation + strong reset; possibly third-party approval |
| In the name of another person | manager approving | only with verified role and specific policy |
| Forbidden on Agent Channel | withdrawal, wage change | not displayed as tool |
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.
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.
| Threat | Description | Mitigations |
|---|---|---|
| Direct prompt injection | user tries to make agent ignore rules | guardrails; authorization does not depend on prompt |
| Indirect injection | indexed document or tool response contains instructions | content treated as data; limited tools; separate instruction and data channels |
| Agency excess | functionality, permission or autonomy (OWASP LLM06) | minimum catalogue; scopes; HITL |
| Confused warehouse | the agent uses its authority for what the user could not | delegation with permissions intersection |
| Token passthrough | server passes token without validating audience | prohibited by MCP; token exchange |
| Exfiltration by exit | sensitive data in response or URL | masking; domain allowlist; no arbitrary links |
| SSRF via discovery | OAuth metadata pointing to internal addresses | URL validation; private track blocking; exit proxy |
| Secrets in Context | keys in prompts or logs | secret safe; tokens out of model context |
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.
| Class | Does it fit into the context of the model? | Does it appear in the answer? | Detention in logs |
|---|---|---|---|
| Public or internal | Yes | Yes | default |
| Common staff | Yes, the holder himself | yes, to the holder himself | short |
| Sensitive personnel (LGPD, Art. 5, II) | only the minimum, with registered purpose | summary to the holder himself | minimum or masked |
| Business confidentiality | no, except authorised tool | no | according to policy |
| Secrets | never | never | never |
Explainability, here, is not explaining the weights of the model: it is telling the collaborator and the auditor which sources support the answer, which rules were applied and by whom, which data the collaborator was used and what the agent did, with which authorization. That gets a lot more direct when the rule is outside the model INFERENCE. In AI governance, the NIST AI RMF gives the risk structure, ISO/IEC 42001 serves those seeking certification and the OWASP Top 10 for LLMs is the technical checklist 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 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.
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.
| Step | The agent does. | The agent doesn't. | Mechanism |
|---|---|---|---|
| Trigger | acknowledges the intention and identifies the process | invent a non-existent process | EXP service catalogue |
| Preconditions | consultation eligibility | decide eligibility | Rule API |
| Collection | pre-fill with system data; asks only what is missing | infer critical data | structured components, state AG-UI |
| Validation | clearly shows errors | ignore validations | field validation |
| Submission | begins the process with idempotence, after confirmation | submit actions with no confirmation | interruption AG-UI + tool |
| Approval | notifies and summarizes the context for the approveer | approve on behalf of the approveer | human task in workflow |
| Exception | detects, explains and forwards with context | resolve the exception alone | exception queue |
| Monitoring | consults the state and explains | promise deadlines outside the SLA | Workflow Status API |
| Closure | confirms the result and offers next steps | declare completed what was only accepted | completion event |
| Case | Volume | Variability | Risk | Suggested approach |
|---|---|---|---|---|
| Consultation of holiday balance or hours | high | low | low | read tool; direct response |
| Request for a holiday | high | low | medium | Initiating agent + confirmation |
| Open call for IT | high | high | low | screening agent (LLM step) and opening |
| Inclusion of dependents | medium | medium | high (sensitive data) | initiator agent + document + workflow with validation |
| Request for access | high | medium | high | agent collects and justifies; mandatory human approval |
| Onboarding | medium | medium | medium | orchestrated workflow; agent as guide |
| Change of post | low | high | high | systemic workflow; agent only informs |
| Shutdown | low | high | Too high | human channel; agent only guides |
Intentions that cross domains (“I’m moving around” involves HR, benefits, facilities, IT and sheet) are journeys EXP, with named owner, implemented as orchestration workflow. The agent conducts the conversation and shows progress; never improvise the sequence Every conversation.
Use AI to compensate poorly defined process is to put an agent in front of a tacit rule, without owner or inconsistent, hoping that the model “resolves”. The result is the tacit rule applied inconsistently, now on a scale. The alternative is to use the discovery of the project to explain rules, exceptions and owners before automating; the agent can even help by analyzing calls and conversations.
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.
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.Papers RECOMMENDATION
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.
| Paper | You ask what only he does | If ignored |
|---|---|---|
| Enterprise Architect | What business capabilities does the platform expose and who owns each one? | agent becomes improvised integrator |
| Integration Architect | API, event or workflow for each interaction? | coupling and inconsistent states |
| Product Strategist | What intentions are worth more and how do we measure resolution? | technology looking for trouble |
| Process / BPM | Is the rule explicit, with owner and exception line? | Inconsistency automation |
| UX Architect | How does the collaborator trust, confirm and resume? | actions without clear consent |
| Front-end Architect | How to compose dynamic UI without breaking the design system? | Arbitrary, inaccessible IU |
| AI Architect | What agent, with what tools and what evaluation? | hallucination and excess agency |
| Content Strategist | What is the canonical source, duration and owner? | RAG on content without governance |
| Search Architect | Does the search respect permissions in the index? | oversharing leak |
| Security / IAM | With what identity does the agent act and with what scope? | generic service account |
| Date & AI Governance | Legal basis, retention, inventory of use cases? | non-compliance with LGPD |
| SRE / Platform | How do we measure quality, cost and latency by intention? | quality silent incidents |
Decisions RECOMMENDATION
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.
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 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.
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.
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.
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.
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.
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.
They give deploy autonomy and charge with shared dependencies, integration tests and consistency.
Balance: adoption conditioned the organizational need measured; modular monolith as standard.
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.
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).
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.
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.
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.
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).
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.
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.
executar_consulta; the same credentials for all.id, texto and vetor.innerHTML with model content; absence of component catalogue.Any “yes” indicates an anti-pattern to treat before broadening the scope.
The matrix compares, does not elect: necessary capabilities; technologies are alternatives to implementation.
| Required (capacity) | Implementation alternatives |
|---|---|
| Federated identity with delegation | any IdP with OAuth 2.x and token exchange or equivalent mechanism |
| Authorization at data point | RBAC + ABAC, ReBAC, OPA or Cedar engines, rules in the registration system itself |
| Contract APIs for used capabilities | REST, GraphQL, gRPC; via gateway and BFF or directly |
| Durable processes with human stages | Temporal, BPMN engines, native SaaS system or platform workflow |
| Content with metadata, duration and permissions | ECM/CSP, CMS headless, productivity platforms |
| Hybrid search with permission filters | Elasticsearch, OpenSearch, managed services, combinations |
| Interaction protocol agent ↔ IU | AG-UI, own protocol, SaaS platform features |
| Generating IU governed | A2UI, MCP Apps, Open-JSON-UI, own design system schema |
| Standard tool interface | MCP, native framework function calls, direct integration |
| End-to-end observation | OpenTelemetry with any compatible backend |
| Continuous assessment | various evaluation frameworks, own tools |
These are not requirements: micro-frontends, Kafka, service mesh, dedicated vector bank, multi-agent, full MACH. Each makes sense in specific contexts.
Operation RECOMMENDATION
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.
Are you up and running? RED/USE metrics, logs, distributed dashes. Owner: SRE and service teams.
What did the agent do and why? Execution spans, steps, tool calls, tokens, model latency, policy decisions. Owner: AI platform.
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.
| Family | Indicator (SLI) | Example of objective |
|---|---|---|
| Availability | executions without RUN_ERROR by platform failure | ≥ 99,5% |
| Latency | time to the first token | p95 < 1.5 s |
| Latency | shift with up to 2 tools | p95 < 8 s |
| Quality | knowledge responses supported by sources (sample) | ≥ 95% |
| Quality | permission leakage in continuous tests | 0 |
| Value | humanless resolution in the intentions empowered | ≥ baseline per intention |
| Cost | cost per resolved intention | ≤ budget per intention |
When quality error budget — 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.
| Category | Metric | Why Does It Matter |
|---|---|---|
| Latency | time to the first token; full shift; by tool; model | user perception and diagnosis of bottleneck |
| Cost | tokens per turn, conversation and resolved intention; cost per model | budget and loop detection |
| Tools | error rate, timeouts, relays, open circuits | health of dependencies |
| Agent | steps per task, replanning, tasks that reach the limit of steps | efficiency and loops |
| Retrieval | empty results, average score, distribution of sources, age of content cited | quality of knowledge |
| Security | policy denials, injection detections, abandoned interruptions | risk posture |
| Quality | sampling groundness, evaluated correction, negative feedback by reason | perceived quality |
| Experience | resolution by intention, scaling, recount, abandonment | value delivered |
Measure by intention, not by the screen: with the dynamic interface, time on the page and clicks lose meaning. Experience metrics are resolution rate, time to resolution, perceived effort, resolution shifts, editing rate in confirmations, step abandonment, scheduling and recount in 7 days. Combined with the telemetry and feeling of DEX tools, they form an independent view of the interface shape RECOMMENDATION.
| Type | Example | Detection |
|---|---|---|
| Availability | model provider out | error metrics |
| Latency | slow system drops shifts | tool latency |
| Quality | reindexion broke the chunking; answers without source | continuous evaluation, feedback |
| Security | restricted content leak | continuous tests of permission, reports |
| Cost | tool loop multiplies tokens | cost alerts per conversation |
| Behavior | the agent started to perform action without confirmation after changing the prompt | regression tests, audit |
For service operation and SRE on another scale, see Service Operations 2.0.
Roadmap RECOMMENDATION
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.
| 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 |
| Criteria | Weight | Why? |
|---|---|---|
| Volume of intentions | high | perceptible value |
| Low risk of action | high | safety in learning |
| Available APIs | high | viability |
| Governable content | medium | quality of responses |
| Engaged process owner | high | receives feedback and solves exceptions |
| Low data sensitivity | medium | reduces the initial compliance load |
HYPOTHESIS “Happiness” (high volume, clear rule, moderate risk) and “IT call” (high volume, low risk) tend to be better pilots than “dependent inclusion” (sensitive data) or “access solicitation” (security risk).
| Risk | Mitigation |
|---|---|
| “Invisible” foundations lose sponsorship | early deliver improved search (phase 2) as visible value |
| Pressure for jumping to stock | explicit and agreed pass criteria with sponsors |
| Change of protocol specification | internal adapters; contract tests |
| Supplier of a SaaS platform launches own agent during the program | explicit decision agent of the platform × independent, revisited at each stage |
| Central Team Dependency | paved paths and distributed tool property |
| Phase | Metrics |
|---|---|
| 0 | inventory coverage; defined baseline |
| 1 | % of pilot content with mandatory metadata; SLO APIs |
| 2 | recall@k, groundedness, leaks (zero), resolution |
| 3 | turn latency, tool error, cost per conversation |
| 4 | action errors, editing rate, exceptions solved in SLA, satisfaction |
| 5 | intent coverage, overall resolution, cost per intention solved |
Readyness RECOMMENDATION
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.
Result
– / 20
Answer the criteria to see the track.
Lacunas (criteria with 0):
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.
| Total | Reading |
|---|---|
| 0 to 9 | little ready for AI: working foundations |
| 10 to 15 | ready for RAG and read tools if listed gaps are not blocked |
| 16 to 20 | candidate for actions with confirmation, provided that delegated identity, governed content and governance are not at 0 |
| Size | Metric | How to measure | Stage |
|---|---|---|---|
| Product | human-free resolution by intention | telemetry + recount | 2 |
| Product | time to resolution | from request to result in registration system | 2 |
| Product | perceived effort | short post-interaction search | 2 |
| Integration | % of priority capabilities with API and versioned contract | catalog | 3 |
| Integration | % of capabilities with published SLO | catalog | 3 |
| Case | % of priority processes with owner, explicit rule and queue | inventory | 3 |
| Content | % of content indexed with duration, owner and permission | metadata validation | 4 |
| Content | time of revocation of the index | events | 4 |
| Search | recall@k and nDCG in the evaluation set | evaluation | 4 |
| Search | leaks in permission tests (meta: zero) | continuous tests | 4 |
| AI | sample groundness | evaluation | 4 |
| AI | accuracy of tool selection | evaluation | 5 |
| Security | % of tools with delegated token and minimum scope | catalog | 5 |
| Security | % of shares with registered confirmation | audit | 5 |
| UX | % of agent screens composed of catalogue components only | rendering telemetry | 5 |
| UX | Editing fee in confirmations | telemetry | 5 |
| Operation | % of executions with trace end to end | observability | 4 |
| Operation | compliance with quality SLOs | panel | 5 |
| Cost | cost per resolved intention | observability | 4 |
| Governance | % of AI use in approved inventory | inventory | 4 |
Regression signs: drop in groundedness after changing model or chunking; increase in editing rate in confirmations (the collection worsened); increase in staggering by “I did not understand”; increase in cost by intention without resolution gain; increasing average age of the quoted content (curacy stopped).
The readiness of a site to be read by agents, on another scale, is the subject of Agent Ready.
Critical questions
Each answer brings the conclusion and the seal that says how much it sustains itself. Open it It matters; the rest is collected.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
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.
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
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.
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.
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.
Read: experience by intention, Generating IU, AG-UI.
Exercise: specify three agent components (confirmation, progress, fonts) with when to use, props and accessibility requirements.
Read: agents and MCP, search and RAG, knowledge, AG-UI.
Exercise: build an evaluation set with 30 real questions, reference documents and groundedness criteria.
Read: operation, front-end and streaming, integration and resilience.
Exercise: set SLIs and SLOs for an intention, including a quality SLO with error budget and the rape runbook.
Read: governed content, knowledge chain, search.
Exercise: apply the minimum set of metadata to ten normative and identify gaps in validity, owner and permission.
Read: identity and governance, agents and MCP, Questions 19 to 30.
Exercise: classify ten hypothetical tools by risk and define, for each, scope, level of autonomy and HITL rule.
In short
It's a corporate portal that stops organize links and passes the resolve intentions: the collaborator asks, the agent prepares, the person confirms and the process runs in the registration system. The agent is a link to a jail — intent, agent, knowledge, tools, process, experience — and depends on the foundations it crosses: if a link fails, it inherits the failure and does not correct it. Without them, he starts to perform actions with too broad credentials and no audit trail.
It is the same principle of autonomy proportional to the evidence of Trust Engineering, applied to the corporate portal.
Frequently Asked Questions
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.
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.
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.
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 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.
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.