I guess many of you have been seeing a huge amount of noise around ‘AI agents’.
It’s certainly a hot topic, whether we’re talking about personal agents working for people, agents for organisations, or AI assistants such as Claude, Muse and ChatGPT.
We have been experimenting in this area, led by our colleague AD, and have built four personal agents so far. This article explores the principles behind the latest one, using a simple example: finding out when the household bins are due to be collected.
Our specific area of interest is in personal agents working for people on a fiduciary basis. That ‘F word’ is critical. The model we are working towards is one in which the provider operating a DataPal personal agent makes an explicit contractual commitment to care and loyalty towards the individual it represents. The agent’s authority comes from that individual, within limits they set.
Like Claude, you mean? Or Muse? Incredible feats of engineering that they are…
Well, that is the question. The video short at the top of this page is what happens when I ask Muse if it can operate for me on a fiduciary basis.
That answer is a useful starting point. But an agent’s description of its own obligations is something we need to check against the terms of the service.
For us ‘users’, the questions are practical: who pays for the service, whose interests does it serve, and what happens when those interests conflict? Free access does not answer those questions. Neither does a subscription fee.
My own take on Muse is that it is an incredible piece of engineering. My concern is whether the incentives and commitments behind services like this will remain aligned with the individual over time. Technical capability alone cannot settle that question.
Our take in the DataPal team is that personal representation needs explicit commitments, clear authority and evidence that those boundaries are respected.
For the personal agents we want to build, the following characteristics are essential:
Identifiers and access — the individual should control the identifiers used to represent them and the credentials or keys that authorise access to their agent. An identifier says who or what is involved; a credential or key helps establish authority to access or act.
Identity — the agent should identify itself as an agent and make clear whom it represents. It should not masquerade as the human responsible for it. The chain of authority must be clear and verifiable.
Orientation — our standard for personal representation is a fiduciary commitment to the individual. Other agents can still be useful, but we want people to know whose interests their representative is committed to serving.
Scope — the agent’s remit must be clearly defined and version-controlled, covering the information it can use, the purposes it can serve and the actions it can take. The individual must be able to inspect, change, pause or revoke that authority. Consequential actions should require explicit approval unless covered by a clearly agreed standing instruction. Any onward delegation must stay within the same limits.
Terms — the terms must be transparent and support the commitment to the individual. IEEE 7012 (MyTerms) provides a basis for standardised, machine-readable privacy agreements. The agent’s authority to take action also needs to be explicitly agreed.
Auditability — both parties should have access to verifiable records relevant to their exchange, showing what was authorised, which terms applied, what information was exchanged and what action occurred. That should make it possible to reconstruct what happened without exposing unrelated personal information.
Some of these controls sit in what developers call the agent’s ‘harness’: the surrounding software that manages its tools, permissions and execution. The commitments and accountability also depend on the people and organisations operating it.
The video below uses a very simple example: a person connecting to a service to find out when their household bins are due to be collected. It gives us a practical way to explore these principles. Tom Loosemore has done a great job of building and explaining WhenIsBins, a Public Digital service that makes council bin collection information accessible to people and their agents.
But the implications go well beyond bins. I see this as a useful testing ground for interactions with more consequential public services, such as checking benefits eligibility. Looking up information can be the first step towards asking an agent to take action. Those are different permissions: authority to check something should not automatically become authority to change it.
Agents can repeat tasks quickly and at relatively low cost, making ongoing help more practical. So the requests might become…
Check whether I may be eligible for additional benefits whenever my circumstances change, and help me decide what to do next.
Check whether my utilities and subscriptions still suit my needs and preferences, and ask before switching unless I have already authorised it.
Help me understand my financial position and prepare decisions that reflect my needs and goals, involving a qualified adviser where appropriate.
Help me manage my fitness and diet around my goals, and prepare questions for a clinician about my medication.
…and many more.
That word ‘context’ keeps coming up. By context, I mean the information that makes a response useful to a particular person: their circumstances, goals, preferences and constraints, alongside the permissions they have granted. What is relevant differs from task to task. A bin collection query needs very different information from a financial planning conversation.
A primary objective of DataPal is to help people connect to their information, making it accessible, under their control and to make it useful to them on agreed terms. That does not require every record to move into one place. Financial records can remain with a bank; health records with a health provider. DataPal’s role is to support the connections, permissions, agreements and records around their use. Each service should receive only the information needed for the agreed task.
The architectural shift is towards a network of permissioned relationships. Today, we often supply and update information separately for each website or app. In the model we are exploring, services can request access to relevant information through connections controlled by the individual, including agent-to-agent interactions. Reading information, updating a record and taking an action each need an appropriate grant of authority.
For individuals, that could mean less repetition and more useful services. For organisations, it could mean clearer instructions and access to relevant, current information. Those benefits depend on participating services agreeing how the connections work and respecting the terms. Existing websites and apps will coexist with this approach for some time.
One of the most tangible benefits could be ‘Tell Them Once’: the long-discussed aspiration that a change in circumstances should not require us to update every organisation separately. A networked ‘subscribe to me’ model could let participating services receive relevant updates with the individual’s permission. Someone could authorise particular organisations to receive a change of address, for example, without giving them access to the rest of their context.
Privacy depends on how this is implemented: limited access, clear purposes, revocable permissions and verifiable records. The aim is to let people coordinate useful connections across services while keeping control over what each party can see and do.
Next up for our agent work and write-ups: we move from bins to financial planning.
Want to try Privacy Pulse yourself for Free, scan your own website and see what score and grade you get?