When the portal user is an agent.

The shift was not a launch — it was a traffic mix

For two years "AI in the portal" meant a chat bubble in the corner. That framing is over. The real change in 2026 is a mix-of-traffic shift: a measurable share of sessions on B2B portals now originate from an assistant acting for a logged-in buyer. The assistant is not a curiosity behind a feature flag; it is on the buyer's laptop, on the buyer's phone, increasingly inside the operating system the buyer logs into in the morning. The buyer asks for a thing — re-order the consumables, chase the open invoices, file the KYC packet — and the assistant traverses the portal to get it done.

Two adjacent moves accelerated the shift. The first was the consolidation of Model Context Protocol as a baseline enterprise primitive — we wrote separately about why multi-agent orchestration and audit trails for agentic flows became load-bearing once the protocol layer settled. The second was the entry of AI-first hardware: assistants running with system privileges, able to act on a window the user never sees. The result is a portal whose hardest traffic to design for is not the new buyer on a mobile browser, but the assistant rendering the page on a headless tab with a five-second budget.

The portals that designed for this shift early are picking up disproportionate share. The ones that did not are running the same UX they shipped in 2023 and watching conversion drop with no obvious culprit, because the failures do not look like failures — they look like agents that quietly hit a blocker and moved on to the next vendor in the buyer's allowlist.

What an agent actually needs from a portal

The temptation is to think of "an agent" as a power user with bad eyesight. That framing fails because the agent is optimising a different cost function. The human user is paying with attention; the agent is paying with tokens, time and trust. A portal designed for the agent makes those three cheap, in that order, without breaking the portal for the humans still on it.

1. A surface the agent can read in one pass

The agent does not want to scroll. It wants the structure of the page available as data, not as pixels. In 2026 that means every meaningful surface ships with schema.org annotations, JSON-LD blocks for the canonical entities the buyer can act on, and a sitemap that tags machine-actionable routes. The portal that exposes a clean application/ld+json for an invoice, a purchase order, a vendor profile or a document submission saves the agent a multi-step DOM crawl and shaves a third off task time. It also stops costing tokens that the buyer eventually sees as latency, then as failure.

2. Agent-mode endpoints with intent, not screens

Forms are made for the human field of vision. Agents prefer intents. The pattern that is consolidating is a small set of agent-mode endpoints — clearly named, scoped per resource, documented with examples — that accept a structured intent and return a structured result. The same portal still serves the human UI; the agent surface lives next to it, not under it. Vendors that expose only a screen-shaped API force the agent to scrape and fill forms, which means every redesign breaks every assistant the buyer uses to reach the portal.

3. Authentication built for delegation

Browser sessions were built for a person sitting at a machine. Agent sessions are not. The auth shape that survives enterprise diligence in 2026 is OAuth 2.1 with PKCE, scoped access tokens issued for the agent acting on behalf of the user, short lifetimes, and an explicit consent screen the user sees before the agent's first action — not the hundredth. Long-lived API keys pasted into an assistant are the new password reuse. The enterprise buyer's security team has already started failing portals that allow them.

4. Scope bounded per session, not per role

The human "role" model — admin, manager, viewer — does not translate cleanly to an agent. The buyer wants the assistant to chase three invoices for one supplier, not to "act as admin." The portal that wins models that distinction: per-session scope tokens, narrowed to a verb, a resource and a time window, with a kill switch the buyer can pull without a ticket. Anything else means a single prompt-injected document opens the buyer's entire account, which we covered separately in the prompt-injection piece.

5. Telemetry by intent, not by click

The classic product analytics model — funnels of clicks, page views, time on page — degrades fast when half the traffic is headless. The replacement that works is intent telemetry: the portal logs which structured intent arrived, from which agent, on behalf of which user, with what outcome, and how long the path took. That stream is what lets product teams spot a regression that only shows up when the agent calls the flow at 4am with a slightly different payload. It is also the only thing a regulator will accept as evidence that "the agent did X on the user's behalf" — see the audit-trail piece for what that record needs to contain to survive diligence.

6. A human fallback the agent can call without losing context

The best agent designs do not pretend to handle every case. They hit an exception, ask for a human, and pass the context cleanly across. The portal that supports this exposes a first-class handover surface: same session token, same case identifier, same evidence package, a UI link the human can open with one click. Portals that force the agent to "abandon and re-open" lose the cases that mattered the most, because those are the exceptions where the buyer's trust was already thin.

The agent is not a power user with bad eyesight. It is a different buyer paying with tokens, time and trust. Design the portal for that buyer and the human one still works. Design only for the human and the agent leaves quietly.

The playbook that is consolidating

Across the portals we work with — supplier onboarding, invoice submission, claims, KYC packets, document repositories — the agent-ready shape is consistent enough to write down. Four moves cover most of the value.

None of the four is exotic. The reason they still feel future-dated is operational: each move sits across three teams that historically did not coordinate — product, API platform, and security. The portals that ship the playbook early are the ones whose CAIO put it in the operating-model artefacts instead of leaving it to a quarterly roadmap fight.

Anti-patterns that quietly disqualify a portal

Failure here is rarely loud. The agent does not file a complaint; it falls back to a different vendor or to a human-in-the-loop on the buyer's side. Three patterns cover most of the silent disqualifications we see.

Form-only flow with no machine surface

The portal exposes a beautiful multi-step form for the human. There is no JSON-LD on the page, no agent-mode endpoint behind it, and the only way to submit is to fill the form. An agent can do it — but it pays in tokens, in latency, and in breakage every time the front-end team ships a new layout. The buyer's assistant gets through twice, fails on the third try, and the buyer loses confidence in delegating the workflow to the assistant. The portal team never sees the failure because the agent's logs are not in their stack.

Auth assumed to be a browser session

The portal's auth flow is built around a CSRF token, a cookie and an interstitial. The agent receives a redirect it cannot follow, a captcha it cannot solve, or a "click here to continue" it cannot click. Where the portal does offer an API key, the key is long-lived and tied to the user account — a compromise of the assistant compromises the whole account. Security review catches this on the way in; the portal team finds out months later, when the procurement loop comes back with a redline they did not anticipate.

No handover surface for the exception

The agent does 80% of the case, hits an edge, and there is no clean path to a human. The platform's review queue is in a different app, with a different login, and no way to drop the case in mid-flight with the evidence attached. The agent emails a summary, the human opens a new ticket, the context is gone. Exceptions are where the regulated buyer is most sensitive to error, so this is the anti-pattern that costs the deal even when the rest of the portal is well built.

What this looks like for document AI specifically

Document AI sits at a particular point in this shift. Documents are the artefact that most often travels between the agent and the portal, and document workflows are the place where the agent's economic case is most obvious — chase the missing invoice attachments, file the KYC pack, submit the claim with the right evidence. Four design choices change for a document pipeline when the requester is an assistant.

Schema-first responses, not human summaries. The classic IDP response is a friendly extraction summary with a confidence bar. The agent does not want the summary; it wants the schema. The pipeline ships the structured result first, with the confidence per field, the bounding boxes for the agent to attach as evidence, and the human-readable narrative as a sidecar. The same payload still drives the review UI for the cases that need a human, but the agent traverses the schema branch and is done in one round-trip.

Intent-bound extraction, not generic dumps. The agent rarely needs every field on the document. It needs the seven fields its current intent depends on. The pipeline accepts the intent — "verify supplier bank account against last invoice" — and returns only what the intent asks for, with the evidence trail for those fields. The token bill drops; the security review gets easier; the audit artefact gets cleaner because the response is scoped to a stated purpose.

Idempotency the agent can rely on. Agents retry. The pipeline that does not give them an idempotency contract creates duplicate cases, duplicate write-backs, and a queue of human cleanup that the platform did not bill for. Idempotency keys on every agent-mode endpoint, with a clear replay semantic — same key, same result, no side effect — is what turns "the agent is fine 95% of the time" into "the agent is fine all of the time."

A handover that carries the page hashes. When the agent can't finish — manuscript-heavy, ambiguous layout, suspected fraud — the handover to the human reviewer carries the page hashes, the model version, the prompt version and the partial extraction. The reviewer opens the case with the evidence already loaded; the agent's session token, scoped to the case, is what the reviewer inherits. This is the part of the design that buyers in regulated sectors test first, because exceptions are where their regulator looks.

Where the category is still half-built

Two pieces of the agent-as-user story are still moving, and any portal team adopting the playbook in 2026 should know which assumptions are durable and which will be relitigated.

The discovery layer is not settled. Schema.org plus a sitemap covers most of what agents need today, but the way assistants find and rank vendor portals is the next contested layer. Some buyers' assistants follow an explicit allowlist managed by procurement; others discover portals through a marketplace; others read open directories. Designing for one of these and ignoring the others is the same mistake the early-2010s mobile-only sites made. The defensible move is to publish the machine surface and register it everywhere; the operating-model owner should treat agent discovery as a quarterly review, not a one-time launch.

Agent identity is half a standard. The portal can authenticate the user; it can scope the token; it still cannot, in most cases, prove cryptographically which assistant is on the other end. A shared identity layer for agents — signed attestations of model version, vendor and consent — is emerging but not yet table stakes. Until it is, the practical defence is intent telemetry plus rate limits plus a kill switch, with a clean rollover plan for the day the standard settles. Vendors that pretend the standard is already here misallocate engineering; vendors that pretend it will never arrive misallocate trust.

Closing thought

The agent-as-user shift is not a new product surface; it is a new traffic mix that exposes whether the existing product surface was honest about its contracts. The portals that designed around intents, schemas, delegated auth and intent telemetry from the outset answer the agent and the human with the same engine. The portals that treated those as roadmap items spend 2026 retrofitting under deadline, with a buyer's assistant already deciding which vendor's portal is worth talking to.

At Cogneris we build document AI as an agent-reachable pipeline by default — schema-first responses, idempotent agent-mode endpoints, delegated auth, intent-scoped extraction, signed evidence packages. We did not call it "AI-first interfaces" when we shipped it; we called it the only shape that survives a regulated buyer's review. If you are mapping your portal against the agent-as-user playbook and want to compare what the document layer should look like, see our product page, the agents documentation, or talk to our team. We would rather have the agent-readiness conversation in the first 10 minutes than read about it in next quarter's churn report.