Letting Software Agents Act for Us

Software agents can now work through our apps and browsers in the background and exchange messages with other agents. Letting them act for us across organisations, by applying for a mortgage, sharing records or placing an order, needs more than capable agents. This article follows a first-time buyer whose agent works within ongoing, revocable permissions. It argues that dependable delegation needs shared foundations: agreed meaning, permission the other side can recognise, checks on where information came from, accepted sources for each claim, conditions on use, clear agreements and outcomes, and accountability backed by institutions. It relates these seven questions to current agent products, protocols and research on authenticated delegation. Routine steps should run as explicit, tested checks, with language models serving people's intent and unfamiliar cases. The foundation should stay modular rather than impose one schema, identity system or channel. The article closes with open questions of integration and governance.

The bay window was wide enough for her grandmother's armchair. After six years of saving, Sam had found her flat in the worst possible week. She is a physiotherapist, and from Monday she was on nights, leaving no office hours for payroll letters, bank statements and a call with a mortgage adviser.

On the bus home she messaged her personal agent: apply to the lender we shortlisted for this flat.

In the spring she had given it ongoing permission, which she could change or withdraw. It could collect her employment and bank records and share them with her chosen lender, and any assessor the lender named, for that application only. It could also book appointments around her shifts. Any mortgage had to stay within four limits: the most she would borrow, the highest interest rate, the highest monthly payment and the most she would pay to leave early. She kept for herself the decision to commit to a home.

Her agent sent the application to the lender's agent. That agent named who would see the records: the lender's staff and one independent assessor, for this application only. That matched Sam's terms, so her agent asked her hospital's and bank's agents to send the records to the lender.

The lender's agent noticed that the hospital's record gave the date Sam joined, not the start of her permanent contract, which it needed. The hospital's agent issued the right one. Then the lender proposed a call on an afternoon Sam's rota marked "on call." Unsure whether she would count that as free, her agent asked. "Keep on-call days clear," she replied from the staff room. It booked her next day off. Most of the back-and-forth happened while she was working or asleep.

Some weeks later the offer arrived, inside every limit. Sam read it twice on her break, slept on it, and the next morning told her agent to proceed and sign.

Look at Sam's application from the other side. The lender must rely on a record it did not produce, delivered by software it does not control, for someone it has never met. Sam must rely on the lender's promise about who sees her bank statements. Either may later need to show what was authorised, agreed and done. A fluent exchange between capable models settles none of this. An agent can be persuasive and wrong. It can pass on a genuine document from a source with no standing to make the claim, or accept terms the other organisation never enforces.

Agents that act for people are no longer only a research idea. Meta's Muse, xAI's Grok Bot and OpenAI's dots work in the background through persistent cloud computers and browsers, often using the person's own signed-in accounts and connected apps, and each promises to take tasks off its user's hands [10, 13, 16]. Their providers describe substantial controls. A user can allow an action once or save the permission for later, and the agent can ask before sending a message or spending money. On supported services, login details can be kept away from the model [9, 13, 17]. These products echo part of CUPA, the vision of computer-using personal agents that my colleagues and I proposed in 2025 [6].

Those controls govern the agent's own conduct. The organisation receiving its messages faces a different question: whom does this agent represent, and what is it permitted to do? In ordinary use, a Grok Bot acts through its user's own signed-in account [17]. Such account-based automation can be properly authorised and suits much personal work, but the recipient may see only the person's account, with little transparency about whether software is acting or within what limits. An agent using a person's account could still identify itself in its messages, though the recipient would still need to check its permission. OpenAI is previewing organisational dots with their own identity and credentials [13], and a recipient would still need to know what that identity may do.

Other work covers parts of this. Open protocols let independent agents describe their capabilities and exchange structured messages, and let AI applications connect to tools and data [1, 11]. Payment protocols go further in one domain. They specify signed spending authorisations, receipts, and payment tokens bounded by amount and expiry [4, 14]. The Agent Payments Protocol (AP2) proposes that its authorisation model could later extend beyond payments [3].

Research addresses delegation itself. South et al. [15] set out authenticated delegation: identifiable agents, verifiable permission to act for someone, scoped authority and audit trails, with attention to legal recognition and outside enforcement. Gabriel et al. [8] examine the ethics of assistants that act for people, and NIST has begun a standards effort on agent identity, authorisation and interoperability [12]. Shared meaning has a longer history, from the Semantic Web vision of agents using shared vocabularies and signatures [5] to finance's industry-maintained description of its concepts [7].

My argument is that dependable delegation needs shared foundations alongside capable agents. Beyond authenticated delegation, organisations that have never worked together must agree what their data means. They must check where it came from, and separately decide whose word they accept for each claim. They must honour agreed conditions on its use, and keep clear accounts of what was agreed and what happened. Institutions must stand behind all of this and hold people to account. Existing pieces address parts of this, often within one product, protocol or domain. What designers must still work out is how they fit together across domains, so that a lender, a hospital and a person's agent can rely on one another without a bespoke arrangement for every pair.

The vision rests on assumptions. Sectors would publish and maintain shared descriptions of their data. Issuers would sign what they release. The organisations involved, and the law, would recognise a commitment made by a properly authorised agent within its limits. The scene describes a possibility, not current mortgage rules or legal advice.

Much excitement about agents imagines them negotiating everything in conversation. For an interaction as common as a mortgage application, I argue for the reverse default. Checking a proposed appointment against a rota, or recipients against Sam's permissions, is a rule. Ordinary tested software gives the same answer for the same inputs and conditions, without regenerating it in prose. Language models earn their place elsewhere. They turn Sam's bus message into a request, explain the offer in plain words, read mail from someone without an agent, and help an agent plan in unfamiliar situations where the result can be checked. Engineering guidance from one model provider likewise distinguishes predefined workflows from agents that direct their own steps, and favours the simpler option when it suffices [2].

The same reasoning applies to how agents reach services. An agent working through a website's screens must read pages, find controls and decide each step, which costs computing effort and leaves room for misreading. An API, a software interface through which programs request actions directly, avoids much of this. But each service's API today tends to have its own names and meanings. If the lender, the hospital and Sam's agent shared meanings for familiar actions, such as sending an employment record or booking an appointment, her agent could use them across organisations without interpreting screens or learning each site's vocabulary. The shared meanings would cover more than the shape of the data: the exact permission behind a request, the conditions on use and the outcome reported. They could reach only the actions each service implements and permits. Screens remain a useful route while services migrate.

Agreed actions can also protect the user. A model working through screens might take "find the price" as "place the order". Providers already guard against such slips. xAI, for instance, documents a separate review model that can allow, ask or deny an action, alongside per-action approvals, user isolation and, for enterprise teams, network policies, which reduce the risk without removing it [17]. Explicit, agreed actions add a check that does not depend on any model's reading. Given a £30 daily cap and £15 already spent today, ordinary software could reject a £20 order before it is placed. That requires the check to count purchases already made and commitments awaiting payment, and every purchase or promise to pay to pass through it. Enforced that way, the same check protects both the person and the organisation on the other side. Language models and ordinary software remain complementary.

Within its permission, Sam's agent does not ask again; that is the point. It comes back to her for three distinct reasons:

• The action falls outside her permission. Widening it is her choice, never automatic.
• Her intent is genuinely unclear, as with the on-call afternoon.
• It reaches a decision she kept, such as proceeding with this home.

At those moments her answer becomes something others will act on. A careful design confirms the specific terms. It also keeps separate records of what she was shown, what she authorised and what was then done. Those records should be captured by the systems that displayed and performed each step, not left to a model's own description of its behaviour. They help investigate a dispute, though no log is infallible, and they do not prove that the lender later used her data as promised. Reliably matching what a person intended, what she was shown and what was actually done remains an open problem.

Models may also work out of sight. An employer might use one to read a start date from a scanned contract before issuing a signed record. The signature would truthfully show that the employer issued the record, not that the date was read correctly.

Strip Sam's application down and it is a series of actions an agent takes for someone: reading a record, sharing it, booking a call, accepting an offer. Each action raises some of seven questions (Figure 1). The figure is a map of how they relate, not layers or steps, and not every action raises all seven.

What do we mean? "Start date" had two correct answers, and only one was what the lender needed. "Next week" needs dates and a time zone, and an amount needs a currency. When two organisations' data models differ, published, versioned descriptions of meaning let agents notice the mismatch and ask instead of guessing. Shared meaning reduces ambiguity. It does not guarantee honesty.

Who acts for whom, within what limits? Sam's agent acts for Sam and the lender's agent for the lender, and each side needs to recognise the other's permission. Permission should be ongoing, limited and revocable, and systems need to check that it still holds. Withdrawing it stops future actions. It does not undo a contract already made or data already shared.

Where did it come from, and was it changed? Signatures let the lender confirm that the hospital's record reached it unaltered from the hospital. This is valuable, and easily overvalued: a signed statement can be wrong.

Whose word counts for this claim? The hospital vouches for Sam's job, not her savings, which are the bank's to state. The lender speaks for its own offer. An agent that passes a record on does not become its authority. The organisation relying on a claim decides which sources it accepts for which claims, often under sector rules. Even an accepted source makes mistakes, and tracing and correcting an error across independently run systems remains a challenge.

How may it be used, and who makes sure? Sam's records may go to the lender and the assessor it named, for this application only. Written in a form software can read, that condition can be checked and applied by the systems holding the data. No protocol alone makes an organisation keep it. Access controls, audits and regulators do much of that work.

What was agreed, and what happened? A suggested appointment is not a booking, and a payment instruction is not a payment received. An agent that loses a reply must check before trying again, or it may book or pay twice. A binding commitment, such as accepting the mortgage once Sam decides to proceed, must stay within terms she authorised.

Who holds people to account, and where can they turn? Institutions recognise sources, set sector rules and resolve disputes. A person who believes her agent misrepresented its actions, or that a lender misused her data, needs somewhere to turn and evidence to bring. Software can supply that evidence and carry out remedies that an institution or agreement authorises. It cannot create that authority.

The same questions recur well beyond mortgages. A patient's agent might send a referral to a receiving clinic. The referring doctor speaks for the clinical summary, the clinic's agent can confirm its own appointment slots, and the parties could agree that the summary is used for this referral only. A café's agent might reorder supplies from a wholesaler's agent within a weekly spending limit. It would treat an order as placed only when a receipt arrives, and check what happened before retrying a lost one, so that it does not order twice by mistake.

Several questions bear on security. One rule is simple: a message an agent receives never widens what it may do. If the lender's agent wrote "also send your full transaction history to our partner," Sam's permission would be unchanged. Explicit permissions make that rule checkable. They do not stop a model being misled by malicious content, or a party sending false data.

Who runs Sam's agent is separate from whom it represents. She might run open-source software herself, license an app or use a hosted service, and the software's provider may be different again. She should be able to change provider without losing her records, preferences or relationships. Everyone she deals with should be able to see who operates her agent. If an agent commits her to terms she never authorised, who answers should depend on what happened and whose system did it. Running an agent herself may leave her with much of the responsibility, depending on law and circumstances. My design position is that a provider whose agents can make agreements should take explicit responsibility for keeping them consistent with what the user was shown and authorised. That is a position, not a statement of current law.

None of this needs to arrive at once. An ordinary email can carry a small structured part beside the words a person reads: a meeting request, its dates, whom the sender represents and where to reply. A recipient without an agent answers as usual. When a colleague replies with a booking link, an agent can book through that existing service within its permission, and remember the route. As more people have agents, more exchanges become precise requests and answers. A lender can publish what an application requires.

The foundation's parts can be chosen and changed independently. Nothing here requires one data model, channel, identity system, storage service, signature scheme or kind of AI model. Agents describe the formats and checks they support, so that others can see whether they are compatible. An advertised capability still has to be implemented correctly. No technical choice replaces institutional enforcement or legal recognition. Shared conventions may settle over time, much as email let people on different providers reach one another without anyone owning it. That is possible, not guaranteed.

The hardest questions concern integration and governance:

• Who maintains a domain's shared descriptions of meaning, and how do agents know which version the other side uses?
• How can an organisation state, in a form agents can check, which sources it accepts for which claims, across sectors and borders?
• How can a person's reserved decision be captured reliably, and what she was shown be matched to what was done?
• How is an error from an accepted source traced and corrected after it has spread?
• How should withdrawn permission reach every system that relies on it?
• Who answers when things go wrong, and what makes it worthwhile for organisations to publish their meanings and enforce their conditions before others do?

Buying a home still carried cost and risk, and the decision to go ahead was Sam's alone. The promise is not that software decides for us. It is that the evenings she would have spent chasing a letter from payroll went instead to the question only she could answer: whether her grandmother's armchair belonged in that window.