Agents are multiplying. Context is not.

There is no shortage of AI agents right now. They book meetings, write emails, summarise documents, answer questions. Most of them are capable. Most of them are also stateless. They know nothing about you when you arrive, they learn nothing when you leave, and whatever you told them in between stays with them — not you. This is the quiet problem at the centre of the current agent boom. Capability is not the bottleneck. Context is.

Organisations have understood this for decades. Recommendation engines, preference matching algorithms, purchase history analysis, the entire machinery of modern commerce exists to build a picture of what you want so that it can be acted on. The problem is who holds that picture, and whose interests it serves. Today, the context lives with the organisations. It shapes what you see, what you're shown, and what you're nudged toward, without your knowledge, on their terms.

Take these examples, just one of many in the current world of ‘Big AI’….

I guess not many people read those privacy policy links….

And is anyone going to click ‘Learn more’ on this one?

At DataPal, we've been building toward a different model, one where the individual holds their own context, and agents work from that store rather than building parallel versions of it on every platform they touch. Over the past several months, we've put three concrete implementations of that model into production.

‍What We Built

‍‍The Buyer Agent was our first proof of concept, and deliberately simple. The questions it was designed to answer were infrastructure questions:

Can an agent authenticate with DataPal and read a user's saved buying intentions?
Can it write new ones back?
Can every one of those actions be cryptographically signed via JLINC?
And can that audit log itself be stored to DataPal as a verifiable record of what the agent did?

The answer to all of these was yes.

That sounds modest, but establishing a working read/write/audit loop with real personal data infrastructure, under the user's own control, working for them on a fiduciary basis, governed by their terms is the foundation everything else builds on.

The Requirements Detail Agent is what comes after that foundation is proven. It does everything the Buyer Agent established: authentication, DataPal read/write, JLINC-signed audit trails stored back to the personal context, and then goes further. Through a structured conversational flow, it elicits a rich, detailed shopping intention from the user: category, specifications, budget, constraints, timeframe, brand preferences. It asks targeted questions across multiple rounds, avoids repetition semantically, and saves the resulting intention as a fully formed "Thing I Want" record in the user's DataPal vault. In other words, the real detail of what the person is in the market for is generated and stored on their side; and only made available under their terms (PDC Intent from IEEE 7012/ MyTerms).

‍This is where personal context enters the picture properly. What the Requirements Detail Agent produces is the same kind of signal that recommendation engines and intent matching algorithms spend enormous resources trying to infer, except it is explicit, user-authored, and held by the individual rather than the platform. There is no inference, no tracking, no behavioural modelling. The user states what they want. The agent helps augment it in conversational form, then captures the end result faithfully. The context lives in their vault, available to any agent they choose to grant access to, on their terms. What does that enable? Think in terms of entering a search query with maybe fifty words, rather than the usual two or three.

Here’s an example; the first step of someone looking to move home.‍ ‍

And in the personal context…

Smart Receipts closes the loop on the other side of a transaction. When you forward a purchase confirmation email, the agent parses it using a locally-run language model, structures the receipt, and posts it back to your DataPal account, signed and auditable. Your transaction history accumulates in your vault, not just in a retailer's database. What you bought, when, from whom, at what price: yours, portable, ready to be used for price comparison, building future shopping lists, expenses, warranties, budgeting, or tax.

Here’s an example…both the generation, and then storage in the personal context.

Then the end result.

Together, the three agents cover an arc.

The Buyer Agent proves the infrastructure works.
The Requirements Detail Agent puts rich, intentional context into that infrastructure, context the user controls.
Smart Receipts captures what actually happened and returns it to the same place.

Why the Personal Context Changes Everything

These agents don’t sound remarkable in isolation. Conversational assistants, email parsing, preference capture, none of these are new ideas. What changes the picture is where the data lives, its richness, depth and veracity; and the terms on which it might then be shared.

DataPal operates as a personal data intermediary. Your intentions, preferences, and transaction records are held under your own controlled, signed with your Decentralised Identifier, governed by your terms, portable across any agent that has your permission to read them. When the Requirements Detail Agent saves an intention, it is immediately available to any other agent you authorise. When Smart Receipts captures a purchase, that record is yours to use however you choose.

This is the fiduciary model in practice. Each agent has one job: serve you. Not the retailer. Not the platform. Not the algorithm optimising for engagement. The data flows to you, and from you, not around you. Of course the retailer, the platform, the app can all benefit; but only once they accept that they agree to the individual’s sharing terms, not their own.

The contrast with the existing model is structural. Recommendation engines build context about you in order to influence your behaviour. DataPal agents build context with you in order to execute your intentions. The information is similar. The direction of power is entirely different.

Accountability as Infrastructure

As we wrote in another recently published post, the question AI builders need to ask is simple: “if something goes wrong tomorrow, can you prove what your agent did today?”

Every action each of our three agents takes concerning your data is cryptographically signed using the JLINC protocol— a verifiable event record that travels with your data. When an intention is saved, that event is signed. When a receipt is parsed and posted, that event is signed. The audit trail is not a logging afterthought bolted on for compliance. It is part of the architecture, and it is stored in the same vault as everything else: yours to inspect, download, or present as proof. Think of that as like a bank statement for your personal data. If truth be told, bank statements might be a bit boring to most and rarely looked at. But without their existence as ultimate proof of something that happened then much of the banking system would fail. The same will apply when we start to think in terms of banking for our data; gaining interest on it (that’s for another post…).

An agent that operates without that accountability is a black box. An agent that produces a signed, portable record of everything it did on your behalf is something you can and will actually delegate to.

The Broader Pattern

These three agents are implementations of a pattern, not a complete product. The pattern:

Personal context held by the individual
Agents authorised to read and write it
Cryptographic accountability for every action

…applies to any domain where people interact with organisations over time.

Property searches. Insurance renewals. Healthcare records. Employment histories. The same architecture that lets the Requirements Detail Agent save your shopping intention today is the same architecture that lets a fiduciary agent represent you in any of those contexts tomorrow. The context does not change. The agents that read and write to it can be as varied and specialised as the relationships they serve.

The technology is not the obstacle. The data infrastructure, who holds the context, under what terms, with what portability, is what determines whether agents genuinely serve the people who use them or simply extend the existing model with a more convincing conversational interface.

DataPal's position is that individuals should hold their own context. Agents should work from it, with permission, transparently, and with a verifiable record of everything they did. What recommendation engines do for platforms, fiduciary agents can do for people, with the crucial difference that you own the result.

Many agents. One personal context, owned and controlled by the individual. That is the direction.

Footnote and a Call to Action

If you are:

Designing smart data schemes
Regulating data exchange
Building platforms or AI systems

Then the question is NOT:

“How do we implement another scheme?”

But:

“Are we building towards a network or away from one?”

We’re currently partnering with a small number of Organisations and Partners to explore these ideas through targeted proofs of concept. If you’re thinking seriously about the future of Smart Data, AI, and individual data control, we’d be interested in hearing from you.

Book a Discovery Session