# AgentWeb: Authenticated Execution Infrastructure for Agent-Native Business Work

Technical whitepaper for partners, agent platforms, and business operators.

## About this whitepaper

Your agents can reason. Your business needs secure completion.

The next bottleneck is not model capability alone. It is the gap between intent
and trusted execution: identity, account state, permission, payment,
verification, and usage attribution. This paper explains how AgentWeb closes
that gap without turning production workflows into fragile screen automation.

AgentWeb helps teams:

- Turn existing business workflows into callable, permissioned actions agents can complete.
- Separate capability from authority so an agent cannot cross users, tenants, accounts, or budgets.
- Replace screenshot-dependent completion claims with typed artifacts, receipts, and verification.
- Track usage by customer, person, key, workflow, and successful action so billing can be trusted.
- Expose A2A, MCP, OpenAPI, and web discovery surfaces that advertise only what the runtime can safely fulfill.

## Table of contents

1. Introduction
2. The business execution balancing act
3. The missing layer: authority-aware execution
4. AgentWeb architecture
5. Action Maps as execution contracts
6. Identity, permissions, payments, and proof
7. A2A, MCP, OpenAPI, and discovery
8. Telemetry, billing, and reliability
9. Security model
10. Implementation roadmap
11. Summary of what we have learned

## 1. Introduction

The internet was built around human presence. A person signs in, chooses an
account, reads context, clicks a control, approves a payment, interprets
confirmation, and knows when something is complete. AI agents invert that
assumption. They can reason over instructions and call tools, but they still
need a reliable way to complete authenticated business work.

AgentWeb is designed to be that execution layer. It exposes business workflows
as bounded tasks with explicit authority, durable state, typed artifacts, and
usage telemetry. The goal is not to help agents browse more pages. The goal is
to make real business outcomes callable and safe.

## 2. The business execution balancing act

Product teams want agents to book, buy, submit, subscribe, update, verify, and
resolve. Security teams need the opposite pressure: no secret leakage, no
account mixing, no unbounded spend, no invisible state changes, and no
ambiguous proof.

The hard part is not building another button-clicking system. The hard part is
preserving trust when work moves from a human operator to a delegated agent.
AgentWeb treats this as an infrastructure problem: every action needs an
execution contract that binds capability to authority and proof.

| Pressure | What it means |
| --- | --- |
| Friction | Too many manual checkpoints make agent workflows useless. |
| Risk | Too much autonomy without scoped authority creates security and compliance failure. |
| Trust | The user needs evidence that the right action happened in the right account. |
| Billing | The business needs attribution for who used what and which actions succeeded. |

## 3. The missing layer: authority-aware execution

APIs, MCP tools, browser sessions, and agent cards each solve a piece of the
problem. None of them alone define who authorized a workflow, what account is in
scope, what budget applies, how progress should be tracked, and what artifact
proves completion.

AgentWeb sits above individual interfaces as an execution specialist. A calling
agent delegates a task. AgentWeb evaluates authority, performs the approved
workflow through the safest available path, emits structured state, returns
proof, and records the usage event.

```text
client agent -> AgentWeb task
  -> identify principal and customer
  -> check authority, scope, expiry, and account binding
  -> execute approved Action Map
  -> return typed artifact and external proof
  -> record usage, success state, and billable event
```

## 4. AgentWeb architecture

AgentWeb is a layered runtime, not a single endpoint. Each layer handles one
part of the trust boundary between agent intent and real business completion.

| Layer | Responsibility | Typical surfaces |
| --- | --- | --- |
| Discovery | Let agents and partners find AgentWeb, evaluate supported skills, and route work to the right endpoint. | llms.txt, agents.json, Agent Card, OpenAPI, MCP manifests, action catalog |
| Authority | Decide whether a principal can execute a task now, against which account, with which limits. | API keys, OAuth sessions, connector binding, scopes, expiry, revocation, spend limits |
| Action Map | Convert a human workflow into a reusable machine contract with inputs, states, failures, and proof. | schema, preconditions, state machine, idempotency, rollback posture, verification |
| Execution | Run the mapped work through the safest approved interface and expose progress as durable state. | A2A tasks, MCP tools, REST, SDK, server-to-server integrations, connector sessions |
| Artifacts | Return portable proof that another agent, customer, or billing system can store and inspect. | quote artifacts, authority artifacts, execution receipts, verification artifacts |
| Telemetry | Attribute real work to the customer, user, agent, key, workflow, outcome, and billable event. | scan events, quote events, action attempts, verified completions, latency, failure class |

## 5. Action Maps as execution contracts

An Action Map is the durable product object that turns a human workflow into
agent-callable infrastructure. It is not a script and not a screenshot trace. It
describes the interface, authority, execution path, expected state, failure
classes, and verification requirements for a business outcome.

| Field | What it defines |
| --- | --- |
| Identity | Map id, customer, domain, owner, version, deployment state, and supported protocol surfaces. |
| Interface | A2A skill, MCP tool, REST endpoint, SDK wrapper, input schema, output schema, and error schema. |
| Authority | Required scopes, principal, account binding, approval checkpoint, budget, expiry, and revocation path. |
| Execution | Preconditions, state transitions, retries, idempotency keys, timeout policy, and recovery behavior. |
| Verification | System of record, receipt source, evidence fields, artifact schema, and billable success condition. |
| Risk | Data exposure, write risk, payment risk, compliance flags, rate limits, and explicitly disallowed actions. |

```json
{
  "map_id": "tryhermes.triggers.list",
  "customer": "tryhermes.dev",
  "skill": "list_triggers",
  "input_schema": { "workspace_id": "string" },
  "authority": {
    "scopes": ["trigger:read"],
    "account_binding": "connector_session",
    "approval": "not_required"
  },
  "verification": {
    "artifact": "execution_receipt",
    "success_condition": "trigger list returned from connected account"
  }
}
```

## 6. Identity, permissions, payments, and proof

Capability and permission must stay separate. A workflow can be technically
mapped without being executable for every user. The authority layer decides
whether this principal can run this action, for this customer, against this
account, under this budget, right now.

```json
{
  "authority_id": "auth_01hv...",
  "principal": "user:lauren@example.com",
  "customer": "tryhermes.dev",
  "scope": ["trigger:list", "workflow:read"],
  "account_binding": "connector_session_...",
  "amount_limit_cents": 0,
  "expires_at": "2026-06-01T00:00:00Z",
  "revocation_url": "https://agentweb.us/dashboard/connections",
  "receipt_required": true,
  "verification_required": true
}
```

Payment workflows use the same structure with stricter controls: spend limits,
human approval modes, checkout handoffs, receipts, revocation, and explicit
proof. AgentWeb should never require raw card custody to make agent commerce
work.

## 7. A2A, MCP, OpenAPI, and discovery

AgentWeb should be discoverable as an execution specialist. A2A is the right
external model for delegation because the request is a task with state and
artifacts, not a single isolated function call. MCP and OpenAPI remain important
interfaces beneath that task boundary.

| Surface | Role | AgentWeb use | Boundary |
| --- | --- | --- | --- |
| A2A | Delegation layer | AgentWeb should expose durable tasks such as scan, quote, connect, authorize, execute, verify, and return artifacts. | A2A is where another agent asks AgentWeb to complete work, not merely call a function. |
| MCP | Tool invocation layer | MCP remains useful for current tool access: read, discover, list actions, execute mapped actions, and setup handoffs. | MCP is an adapter. It should not define the whole company or hide missing authority. |
| OpenAPI | HTTP contract | OpenAPI describes stable partner endpoints, schemas, auth requirements, and direct integration paths. | OpenAPI does not itself solve delegated permissions, payment authority, or receipts. |
| Agent Card | Discovery document | The Agent Card should publish identity, skills, endpoints, authentication modes, and artifact expectations. | The card is a public promise. The runtime must make each advertised skill true. |

## 8. Telemetry, billing, and reliability

Aggregate traffic is not enough. Agent-native billing depends on knowing which
customer, person, key, workflow, action, and agent produced a successful
outcome. Telemetry has to distinguish discovery traffic from semantic product
events.

| Layer | Meaning |
| --- | --- |
| Discovery traffic | Path hits, protocol requests, agent user agents, referral surface, and scan entry points. |
| Product telemetry | Quote generated, setup session created, connector linked, action attempted, action verified, artifact emitted. |
| Billing event | A successful verified action that maps to a customer, user, workflow, artifact, and pricing rule. |

```json
{
  "event": "verified_action",
  "customer": "partner_123",
  "user_id_hash": "usr_hash_...",
  "api_key_prefix": "aw_19d78bd59",
  "agent_protocol": "a2a",
  "workflow_id": "order.pickup",
  "action": "submit_order",
  "success": true,
  "artifact_id": "receipt_...",
  "billable": true
}
```

## 9. Security model

Agent-native does not mean unrestricted. It means business work can be
delegated only after the system can prove identity, scope, account binding,
limits, and verification. The security model has to assume agents are
persistent, fast, composable, and able to repeat calls at machine speed.

| Control | Requirement |
| --- | --- |
| Least-privilege authority | Every irreversible action is bound to a principal, customer, account, scope, expiry, and revocation path. |
| Tenant and session isolation | A connected account for one person or company cannot be reused by another user, agent, workflow, or customer. |
| Payment boundaries | AgentWeb should use delegated payment authority, checkout handoffs, receipts, and spend limits instead of raw card custody. |
| Structured refusal | Unsafe, unmapped, stale, unauthenticated, or over-budget requests return typed failures rather than hidden partial work. |
| Privacy-preserving telemetry | Operational data should be attributable enough for billing and debugging without exposing raw secrets or unnecessary personal data. |
| Auditability | Every attempted and completed action should leave enough evidence to answer who authorized it, what changed, and why it was allowed. |

The security question for every workflow: can AgentWeb prove who authorized
this, what was allowed, what happened, what changed, and how future authority
can be revoked?

## 10. Implementation roadmap

The near-term goal is not to claim agents can do everything. It is to make one
valuable authenticated workflow work flawlessly, then generalize the authority
and execution primitives behind it.

| Phase | Focus | Outcome |
| --- | --- | --- |
| 1 | Reliability baseline | Keep the public discovery surfaces accurate, make quote and scan flows fully observable, and show per-user usage in the dashboard and Company Brain. |
| 2 | A2A task server | Expose scan, quote, setup, connect, execute, and verify as A2A tasks with persistent state, structured input requests, and typed artifacts. |
| 3 | One flawless commerce workflow | Choose one high-confidence vertical and make the complete path work from terminal: install, verify, connect, authorize, execute, receipt, and bill. |
| 4 | Action Map system | Turn repeated design-partner workflows into reusable maps with shared authority models, verification schemas, connector sessions, and billing events. |
| 5 | Execution network | Let third-party agents delegate real work to AgentWeb because it is the reliable execution specialist for authenticated business tasks. |

## 11. Summary of what we have learned

Agents need more than access to websites. They need a trusted way to complete
business work. That requires explicit authority, reliable execution, typed
artifacts, privacy-preserving telemetry, and billing semantics tied to
successful outcomes.

AgentWeb should become the execution company agents delegate to when work
crosses identity, account state, payment, verification, or compliance
boundaries. The public promise is simple: bring an intent, an authorized
principal, and a business workflow; AgentWeb returns the action, state, proof,
and usage record.

## Partner next step

Bring one workflow that must become agent-callable.

AgentWeb will map the authority model, execution path, proof requirement,
failure states, and billing event before turning the workflow into a reusable
runtime primitive.