When Software Acts for People

Abstract

AI assistants are beginning to perform work that previously required people to navigate websites, contact organizations, or operate software themselves. Technical standards are advancing quickly. Agents can discover tools, communicate with other agents, and increasingly identify themselves to businesses. But the person who delegates the work often has no independent, coherent account of the authority they granted, what the software attempted, what the receiving organization accepted, and what remains unresolved. Each provider sees its own part of the transaction.

This paper examines that problem and the infrastructure emerging around it. It proposes a possible missing layer: personal software for delegating and accounting for work across agents and providers, paired with simple interfaces through which organizations can accept properly scoped agent requests. The aim is to make ordinary transactions easier to complete and easier to verify while leaving legal authority, official decisions, and appeal procedures with the appropriate people and organizations. The proposal builds on existing APIs and protocols; it does not require a new universal AI agent or a new network before its first useful application.

Executive summary

The web largely assumes that a person visits a service, signs in, completes a task, and receives the result. Increasingly, a person may instead ask an AI assistant to find the service, gather information, take an action, and report back. A single task may involve several software providers and several institutions. The agent's activity log, the service's transaction record, and the person's own understanding are not necessarily consistent.

Much of the emerging infrastructure addresses the other participants. Model and agent providers build execution environments. Tool and agent protocols make services accessible to software. Identity and security vendors help organizations authenticate and supervise automated actors. Financial platforms have begun introducing bounded authorization and auditable agent transactions. These are substantive developments, but their records and controls are usually organized around individual providers or organizations. [1–9]

A complementary layer could operate from the individual's side. It would let people connect compatible assistants and services through a conventional graphical interface, grant limited permissions, approve consequential actions, and keep their own transaction history. A matching provider-side component could translate existing APIs or staff workflows into supported, accountable operations. This is a plausible technical architecture, not a claim that the components already form a universal network.

Public services make the issue particularly important. Agencies must distinguish requests from decisions, establish legal authority, retain official records, and support correction and review. An individual-controlled record cannot confer legal powers on an agent or force an agency to accept its transactions. It can make the chain of delegation and evidence more intelligible, while giving agencies a more structured way to participate. [10–14]

The near-term test is practical: can someone use a single independent application to authorize a narrow task, observe the request and response, distinguish an agent's report from a provider's acknowledgment, and carry the record to a second compatible client? That can be demonstrated with existing APIs, a local database, and a fictional provider service before any agency commits to adoption.

A transaction with more than two parties

Consider someone renewing a local business license. They ask an assistant to check the requirements, complete the application, and tell them when it is done. The assistant replies, “Your renewal is complete.” What does complete mean?

It might mean the assistant found the appropriate form. It might mean it filled in a draft. It might mean a submission was transmitted. The agency might have acknowledged receipt but not accepted the application for processing. A licensing officer may still need to make a decision. Those are different events with different consequences for the applicant.

The ordinary web transaction has acquired new participants: the person, the personal agent, any tools or intermediary services the agent uses, and the organization receiving the request. Each participant can hold a different record. An activity transcript from the assistant is evidence of what it reported; it is not necessarily evidence that the agency received or approved anything.

The same problem appears in private transactions. Someone tells an assistant to cancel a subscription, dispute a charge, or request an insurance update. The service provider may recognize the agent, require additional confirmation, or respond only through a website. The person can end up reconstructing the outcome by opening multiple accounts and comparing separate messages. The problem exists even when no participant is malicious and every system works as designed.

The relevant public-facing question is straightforward: When software acts for me, where can I see what I allowed, what happened, and what I still need to do?

Four missing pieces of the experience

Access without technical expertise

Many integrations are described in terms of APIs, MCP servers, agent skills, OAuth scopes, and configuration files. These abstractions are useful to developers. They are poorly suited to a person trying to resolve an ordinary matter. A consumer interface could present available actions as tasks, explain what a connection permits, and show who provides the underlying service. The Model Context Protocol expressly allows clients to choose their user-interface pattern; it does not mandate a command-line or conversational interface. [1, 2]

Delegation that has understandable boundaries

Traditional account access often turns on broad permissions: read an account, manage a calendar, or write to a service. Delegated work can require narrower instructions: check the application every Friday but do not submit a change; prepare a refund request but ask before sending it; spend no more than a stated amount with an approved recipient. Some financial agent products already apply this kind of policy to transactions, and OAuth-based products support consent and revocation within their own systems. [7–9]

A person needs to see the difference between permission to inspect data, permission to prepare a proposed action, and permission to commit an action. A general instruction to an AI model is not an adequate substitute for enforcement at the tools and services where the action occurs.

A record that distinguishes claims from evidence

An assistant's statement that a task is finished should be labeled as an assistant's statement. A request observed by a controlled connector should be labeled as an observed request. A confirmation issued by the receiving organization should retain its issuer and original contents. Where possible, those records can be reconciled, but they should not be collapsed into a single reassuring “done” status.

The record should survive a change in assistant or vendor. It should be exportable in an ordinary, documented format and understandable without proprietary tooling. This does not require blockchains or a universal reputation score. It requires consistent identifiers, time-ordered events, provenance, and careful treatment of missing evidence.

A way to stop, correct, and recover

Revoking a local agent's tool access, revoking a token issued by a remote service, withdrawing an application, and appealing an official decision are distinct operations. A consumer interface can expose available controls and the correct path for each. It cannot revoke a credential held by an unrelated provider without that provider's cooperation. Nor can a local application create a right to appeal that does not exist under the governing rules.

What already exists

The technical landscape is not empty. It is better understood as several layers that have developed for different customers and purposes.

MCP's July 2026 specification introduced a stateless protocol core, authorization hardening, and an extensions framework. Its tool specification addresses what tools are exposed and how clients invoke them, while leaving the user experience to the implementing application. A2A defines a common language for separate agent systems. Neither automatically establishes the legal significance of a completed government transaction. [1–3]

The Personal Agent Protocol is especially relevant. Sierra and its partners published a draft in October 2026 that describes how a personal agent can identify itself to a company, maintain a session, use APIs, and reach company agents. Its optional Operations extension defines proposed terms, approval, confirmation, tracking, and protection against duplicate execution. The specification is explicitly at draft 0.1 and may change. Its authors also acknowledge that a statement of user approval from a personal agent does not independently prove that the user saw and approved the terms. [4–6]

Identity providers already offer concrete consent management. Stytch documents how an application can show scopes, list authorized connected apps, and revoke access and refresh tokens. Lightspark allows account holders to set limits and approval thresholds for AI agents operating within Grid Global Accounts. Cobo has introduced authorization controls for agent-driven blockchain activity. These are evidence that bounded delegation is technically viable within a participating provider's domain. They do not imply a common consumer ledger across every domain. [7–9]

Government work is underway as well. NIST launched an AI Agent Standards Initiative in February 2026 and is examining agent identity and authorization. Estonia's Reason Reserve (Aruait) project, launched in June, proposes limited and revocable authority for agents, a trust registry, interoperability work, and at least one pilot connecting public and outside agents. These are active initiatives, not completed universal systems. The EU Digital Identity Wallet program is another important precedent for portable, person-controlled credentials, although a credential wallet is different from a record of delegated actions. [10–13]

Taken together, these efforts establish much of the protocol and security basis for a new consumer experience. They do not demonstrate that people already have a neutral, widely supported way to track consequential actions across unrelated agents and institutions.

A possible missing layer: personal delegation infrastructure

A practical response would have two cooperating components. They could be developed independently and should be interoperable with other clients and providers.

The personal component runs on a device controlled by the individual. It provides a directory of compatible services; a graphical interface for selecting tasks; a place to grant, review, and withdraw permissions that it manages; an approval screen for consequential actions; and a persistent record of exchanges and evidence. It can work with different agents rather than requiring the person to adopt a particular model provider.

The provider component lets an organization describe the operations it supports and the authorization each requires. An organization with an established API may need only an adapter. One with existing MCP or Poppy support may expose that interface directly. A smaller organization without a programmatic API could begin with structured intake reviewed by staff, provided it has chosen to accept that channel. It should not have to build its own AI agent to receive structured requests.

The common element is an action record connecting the person's instruction, the agent's proposed operation, the applicable authorization, the observed exchange, and the provider's response. That record is useful to the person even if no second organization participates.

Person
  | chooses task, grants limited permission, reviews results
  v
Personal delegation client and local record
  |                    ^
  | approved request   | observed exchange and outside evidence
  v                    |
Selected agent ---- controlled connector (MCP / API / Poppy)
                              |
                              v
                  Service-provider interface
                   API, agent, or staff queue
                              |
                              v
                 Provider system and decision

There is no requirement that the personal client, agent, connector, and provider use the same hosting company. The interface between components should rely on existing published standards whenever possible.

A transaction record, not a generalized trust score

The record would distinguish the following states: requested, authorized, attempted, acknowledged, decided, and contested. “Completed” would be shown only with a precise meaning, such as the API call finished, the agency acknowledged receipt, or the provider confirmed cancellation. The consumer should not have to infer which meaning applies.

Each event would identify the person or system making a claim, the target service, the task, the relevant permission, the time, and any supporting reference. Where a third party issues a receipt, the original receipt would be retained. Where the system merely observed a response, it would say so. A missing event should produce an unverified status, not a fabricated conclusion that nothing happened.

This structure could also make independent reconciliation possible. A system can compare an agent's description of its work with the activity actually observed at a connector. That comparison is useful for detecting omissions and unsupported claims. It does not verify activity outside the connector's visibility or prove that the responding organization fulfilled a legal obligation.

Public services are an important test of the model

Government transactions expose distinctions that commercial automation often hides. Agencies make decisions under statutes and regulations, maintain official records, and may owe people notice, review, or appeal processes. A software system can help prepare information without necessarily being legally permitted to sign or submit it.

There are longstanding forms of authorized representation in public programs. For example, federal Medicaid regulation 42 CFR §435.923 provides for designated representatives under specified conditions. Those rules concern legally recognized individuals and organizations. They do not, by themselves, establish a general right for any software agent to act as a representative. [14]

The technical design should therefore separate three questions: Who is asking? What has the person permitted the software to attempt? Will the receiving organization legally recognize the resulting action? Authentication, local delegation, and official acceptance answer different questions.

Existing municipal APIs provide a limited starting point. Open311 GeoReport v2 permits applications to discover service types and query service-request statuses in participating jurisdictions; some operations also allow submissions under the jurisdiction's rules. A client can accurately report the status returned by the API without claiming to know whether a streetlight was physically repaired or a pothole actually fixed. [15]

For federal agencies, recordkeeping is also an existing obligation. NARA's August 2026 guidance explains how the Federal Records Act applies to AI-related inputs, outputs, audit trails, and other materials when they qualify as federal records. A consumer-held passbook would supplement, not replace, an agency's official system of record. [16]

The appeal of a shared model is that people could use similar controls and understand similar transaction states even when government programs differ. The laws and decision procedures remain specific to each service.

How organizations could participate without rebuilding their services

Any network of agent-capable services will expand unevenly. Some organizations already publish usable APIs or MCP tools. Others have only a website, a document upload process, a contact center, or an email inbox. Treating MCP as a prerequisite would exclude much of the public and many of the organizations people need to contact.

A reasonable participation model has four routes:

An open provider starter could offer simple service descriptions, authentication configuration, approval callbacks, transaction IDs, status updates, and a human-review inbox. It should use ordinary HTTP interfaces and exportable data. Adapters and service descriptions could be contributed by developers or published by organizations themselves.

A provider should be able to implement this without joining a proprietary marketplace. Conversely, an individual should be able to connect to an existing supported API without waiting for a provider-specific integration partnership.

A directory of services has value, but listing an endpoint is not certification. Every connector needs a clear publisher, source documentation, permitted operations, data-handling description, and maintenance status. Third-party connectors must not be treated as trustworthy merely because they are discoverable in a registry. The MCP Registry itself describes its role as a metadata catalog, not a blanket assurance of service quality or safety. [17]

The first executable demonstration

A small, runnable implementation could test the entire idea without government integration funding or a paid model subscription. Its objective would be to prove that the personal client can supervise one transaction end to end, and can do so again through a different connection.

A credible first build would include a device-based application; a local SQLite event store; a plain-language task interface; a read-only connector to a documented public API, such as an Open311 endpoint; a fictional provider service that accepts proposed operations and returns confirmations; and an optional MCP adapter so independent agents can participate. The application would run without a language model for the essential actions of viewing a case, checking status, reviewing permissions, and exporting records.

The demonstration could proceed as follows. A person asks the client to check an existing municipal request and prepare a follow-up if it remains unresolved. The client fetches the official status and records the returned data. An agent prepares a suggested message. The person approves the message, but no live submission occurs unless a supported, authorized channel exists. In the fictional provider environment, a separate proposed action can be approved, executed, and acknowledged with a provider-issued reference. The personal record distinguishes those stages.

A second compatible agent or client would then import the same history and continue the work. It would not inherit access tokens or legal permissions automatically. Those remain bounded by the issuing service and the new connection.

This demonstration would test several claims in software: a GUI can hide protocol complexity; authorization can be scoped at the connector; requests and responses can be recorded separately from the agent's narration; a provider can issue a meaningful receipt; and the resulting record can be carried to another client.

The technical components are familiar: TypeScript, a small local application framework, SQLite, documented JSON event shapes, OAuth where available, and adapters to MCP or ordinary HTTP APIs. The novelty would have to be demonstrated in the assembled experience and portable conventions, not attributed to any single library.

Adoption, incentives, and governance

A personal application can provide value before a network develops. It can manage a single supported connection and maintain a reliable record of a useful task. A wider network becomes valuable when people can carry instructions and records between multiple providers and clients. That larger benefit does depend on adoption and compatible implementation.

Providers need reasons to participate. A supported agent-access interface could reduce ambiguous automated traffic, preserve transaction references, define acceptable operations, and route exceptional cases to staff. These benefits should be measured rather than assumed: easier automation can also increase duplicate requests and create additional work for the organizations receiving them.

The commercial arrangement matters as much as the technology. A consumer-facing intermediary that routes people to third-party agents could be paid by its users, by participating services, or by vendors seeking placement. These incentives are not equivalent. Referral payments, hidden ranking preferences, resale of behavioral records, or exclusive integrations could compromise a claim of independence. A serious implementation would disclose compensation, preserve the ability to export data, and allow clients and providers to interoperate without exclusive contracts.

“Broker” and “utility” are useful analogies, but they do not confer fiduciary duties or public-utility obligations. Any proposed standards or operating rules would need to specify what the operator actually promises, what it can independently verify, and where another institution retains responsibility.

The rights and interests at stake are also wider than the person using the agent. A request may contain information about family members, employees, patients, students, or other people who never consented to the assistant's use. Data minimization and permission boundaries should apply to the content of actions as well as the account tokens used to transmit them.

What to evaluate

Before claiming a new sector or standard, a working implementation should be assessed against observable outcomes. The following questions are more useful than a general “trust score.”

Three failures would be informative. If most users only need document preparation, a general delegation client may be excessive. If independent developers cannot adopt the event format, the portability thesis is weak. If service providers gain no operational advantage from structured agent requests, a provider-facing gateway may not become a business even if the consumer interface is useful.

These are reasons to design a real trial rather than assume market adoption from technical compatibility.

Conclusion

An increasing share of online work can be carried out by software acting for people. Standards for agents to access tools and communicate with organizations are advancing, and identity vendors are building substantial controls for organizations. The person's own cross-provider experience is less coherent. A successful delegated transaction can span an assistant, a tool provider, an intermediary, and a receiving organization, with no single record that explains what each actually did.

One possible response is a personal delegation client paired with an open provider-access model. The personal side would offer a familiar interface for connecting services, granting limited permission, approving work, and maintaining a portable history. The provider side would allow businesses and public organizations to participate through existing APIs, supported protocols, or structured human workflows. Shared action and receipt conventions would make transactions easier to understand without forcing everyone onto one AI platform.

This is feasible to investigate now. It does not depend on inventing a new foundation model, requiring every service to implement MCP, or securing universal government adoption. A small executable can establish whether the permissions, observations, and receipts genuinely improve an ordinary person's ability to complete work and know what happened. That is the useful starting point for a larger discussion about delegation, trust, and public participation in the agent-mediated web.

Notes and sources

The sources below establish the present technical and policy landscape as of 15 October 2026. Proposed architecture and evaluation criteria are the analysis of this paper, not requirements imposed by the cited specifications.

1. Model Context Protocol maintainers, “The 2026-07-28 Specification,” 28 July 2026. https://blog.modelcontextprotocol.io/posts/2026-07-28/ . Documents protocol evolution, authorization hardening, extensions, and tools.
2. Model Context Protocol specification, “Tools,” revision 2026-07-28. https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/docs/specification/2026-07-28/server/tools.mdx . Describes model-controlled tools and client freedom to choose interaction patterns.
3. Agent2Agent Protocol, “A2A Specification,” current published specification. https://a2a-protocol.org/v1.0.0/specification . Defines inter-agent capability discovery and communication; server-side authorization remains the provider's responsibility.
4. Sierra, “Sharing a draft of Personal Agent Protocol,” 9 October 2026. https://sierra.ai/uk/blog/poppy . Explains the initial industry publication and design partners.
5. Personal Agent Protocol, “Specification,” draft 0.1, October 2026. https://personalagentprotocol.org/docs/spec . Defines company discovery, personal-agent sessions, authentication, and supported interaction channels.
6. Personal Agent Protocol, “Operations extension” and “Path to 1.0,” draft 0.1. https://personalagentprotocol.org/docs/extensions/operations and https://personalagentprotocol.org/docs/path-to-1 . Documents approvals, operation IDs, duplicate-prevention semantics, stated limits of approval evidence, and areas not yet standardized.
7. Stytch, “Consent management,” Connected Apps documentation. https://stytch.com/docs/connected-apps/resources/consent-management . Documents OAuth consent, connected-app visibility, scopes, and revocation within a participating provider.
8. Lightspark, “Introducing AI Agent Support for Grid Global Accounts,” 4 May 2026. https://www.lightspark.com/news/lightspark/introducing-ai-agent-support-for-grid-global-accounts . Describes scoped, revocable agent permissions and enforcement in a financial account product.
9. Cobo, “Cobo Launches Agentic Wallet,” 20 April 2026. https://www.cobo.com/agentic-wallet/news/cobo-launches-agentic-wallet-how-ai-agents-interact-on-chain . Describes agent authorization and execution controls for supported blockchain activity.
10. NIST, “Announcing the AI Agent Standards Initiative for Interoperable and Secure Innovation,” 17 February 2026. https://www.nist.gov/news-events/news/2026/02/announcing-ai-agent-standards-initiative-interoperable-and-secure .
11. NIST National Cybersecurity Center of Excellence, “Software and AI Agent Identity and Authorization,” 2026 project page. https://www.nccoe.nist.gov/projects/software-and-ai-agent-identity-and-authorization . Current exploration of agent identity, authorization, and interoperable approaches.
12. Estonian Information System Authority, “Reason Reserve / Aruait,” 2026. https://ria.ee/en/state-information-system/artificial-intelligence/reason-reserve-aruait . Describes a 24-month initiative to develop agent authorization, trust registry, interoperability, and pilots; planned outcomes are not reported as completed.
13. European Commission, “European Digital Identity,” current 2026 overview. https://commission.europa.eu/topics/digital-economy-and-society/european-digital-identity_en . Describes the EU Digital Identity Wallet rollout and its identity and credential purposes.
14. 42 CFR § 435.923, “Authorized representatives.” https://www.law.cornell.edu/cfr/text/42/435.923 . Federal Medicaid rule governing designation of individual or organizational representatives under specified conditions.
15. Open311, “GeoReport v2.” https://wiki.open311.org/GeoReport_v2/ . Stable open API specification for participating municipal service-request systems.
16. National Archives and Records Administration, Memorandum AC 11.2026, “Guidance on Applying the Federal Records Act to Artificial Intelligence Materials,” 21 August 2026. https://www.archives.gov/records-mgmt/memos/ac-11-2026 .
17. Model Context Protocol Registry, “About the MCP Registry,” 2026 preview documentation. https://github.com/modelcontextprotocol/registry/blob/main/docs/modelcontextprotocol-io/about.mdx . Describes the registry's discovery and metadata function and its preview status.