If you want to stress-test whether an agentic AI deployment has been thought through properly, don't start with the model. Start with the inbox.
That's the example Carl Jackett, founder of the data consultancy Revello, kept returning to in a recent conversation with Tamas Feher, founder and CEO of Isolio, on Isolio's podcast. It's a deceptively simple case study, and it exposes almost every governance question an agentic system raises, from what data an agent should be able to see to who owns the things it produces.
This is the second article in a series drawn from that conversation. The first article argued that data ownership, not model selection, is the real starting point for agentic AI.
Why the inbox is the perfect stress test
"For most people, including mine, if I'm honest, your inbox becomes this shadow archive of everything," Carl said. Personal conversations, opinions about colleagues and clients, contracts, negotiation positions, attachments containing information that was never meant to travel further than the original recipient: it's all sitting there, unstructured, indefinitely. Give an agent broad access to "check the inbox and handle it," and you've quietly given it access to everything in that archive, most of which you never had explicit rights to share with a third-party system in the first place.
Email is a useful test case precisely because it's mundane. Every business has one. Most businesses would say, if asked directly, that they haven't audited what's actually sitting in it. That gap between assumed and actual data exposure is exactly where agentic AI risk lies.
A four-part framework: inputs, transformations, outputs, governance
Carl's approach isn't a bespoke methodology invented for the AI era. It's standard systems engineering, applied to a new kind of system. Any process, agentic or otherwise, can be described in four parts:
Inputs: What data does the agent actually need to do its job? For an inbox-reading agent, that might be a specific folder, a specific sender domain, or emails matching a defined pattern, not the entire mailbox by default.
Transformation: What is the agent actually doing to that data? Extracting structured fields, drafting a reply, summarising a thread, triggering a downstream workflow. Each transformation is a point where new value, and new risk, gets created.
Outputs: What does the agent produce, and is it genuinely new? A drafted response, a combined dataset, an extracted insight that didn't exist in that form before. Carl calls this "the great potential" of these systems: they can generate proprietary value. But that value needs an owner.
Governance: Who is accountable for the whole chain, and how do you prove it if asked? This is the layer that ties inputs, transformations and outputs back to rights, retention and audit.
"You need to understand your governance model that sort of sits across all of that," Carl said. "A lot of the challenges here are just the same" as any well-engineered system, whether or not AI is involved.
Answering the basic questions, on paper
Applied to the inbox example, the framework turns into a specific checklist: who owns this data, what rights do you have to use it, what rights was it originally captured under, can it be shared with a third party (such as the AI vendor processing it), where is it stored, have copies been created, and how would those copies be deleted if asked.
None of these are exotic AI questions. They already existed for GDPR compliance. What's new is the volume and speed at which an agentic system can act on incomplete answers to them.
Designing for the output, not just the input
One detail is easy to miss and expensive to retrofit: what happens to an agent's output once the original input data is deleted. If a customer exercises a GDPR right to be forgotten, does that cascade into deleting a report, a summary, or an analysis the agent already generated and that your business has since relied on?
Carl's answer is that this is entirely solvable, but only if it's designed in from the start. "That shouldn't affect the output you've just generated from that. You can design that in," he said, "but only if you thought of it first." Concretely, that means separating the new output's ownership from the source data that fed it, so a deletion request removes the original personal data without silently invalidating work product the business has already built on top of it.
Retrofitting that separation after the fact, once dozens of workflows are already running, is a far bigger job than designing it in at the outset.
Don't marry a single model
The same governance discipline pays off when it's time to change providers. Because the framework describes the workflow, not the vendor, in terms of what data goes in, what transformation happens and what comes out, it becomes portable. "What you want is a workflow for your business that you could change the model for," Carl said. If a provider changes its terms and conditions, or a new model materially improves cost or quality, a business with this mapping in place can swap the underlying model and validate the change against a known baseline, rather than starting the risk assessment from zero.
Tamas made the same point from the operator's side: in a properly governed agentic workflow, "the AI part is tiny" relative to the guardrails, structure and validation around it. That's a feature, not a limitation. It means new model versions can be A/B tested against the existing baseline before being trusted with production traffic, and a degraded or discontinued model can be swapped out without rebuilding the whole workflow.
Turning this into a working checklist
For a technical or IT lead evaluating an existing or planned agentic workflow, the inbox framework translates into five concrete questions worth writing down for every agent in production:
- What is the minimum set of inputs this agent actually needs, rather than the broadest access it's currently been given?
- What transformation is it performing, and does that transformation itself introduce new risk?
- What new outputs does it create, and who owns them?
- What is the deletion and retention path if the source data is withdrawn?
- Is the workflow described independently of the specific model powering it, so that a vendor or pricing change doesn't force an emergency rebuild?
Answering those five questions honestly, even for a single workflow, usually surfaces the gap between what a system is technically capable of accessing and what it actually needs. Closing that gap is most of the governance work done.
The next article in this series looks at the accountability side of the same problem: how to treat an AI agent less like a piece of software and more like a new hire, complete with an access review and an audit trail.
This article is drawn from Episode 1 of Isolio's podcast, "Data Ownership and Lifecycle Management in Agentic AI," a conversation between Tamas Feher (Isolio) and Carl Jackett (Revello).