Data-Centric Process Architecture

Section 7 of Agentic Banking Architecture: A Practitioner's Guide

I think our traditional way of describing business processes may not be the right foundation for agentic transformation.

We describe processes as activities performed by people: "the analyst prepares the credit memo, the manager approves, operations books the deal." This fuses together the what, the who, and the how. That worked when we automated with applications and RPA — you still had to specify how to perform each step.

But agents are different. An agent takes a goal and figures out its own approach. You define the what; the agent defines the how. Agents don't need a procedure to follow — they need a description of the transformation to perform.

Why agents change the equation

The executor of a process step has changed before. We've been replacing human activity with coded logic, applications, and rules engines for decades, and RPA extended this to screen-level task automation. But all of these are still activity-centric at their core. When you build an application or an RPA bot, you specify how to perform the step — you translate the human procedure into machine-readable instructions. The executor changes from human to machine, but the fundamental paradigm doesn't: someone still defines every action, every rule, every branch.

Agentic AI is different in kind, not just in degree. An agent can take a goal — "produce a risk assessment meeting these criteria from these inputs" — and determine its own approach. It can decide which data to examine first, what tools to use, what intermediate steps to take, and adapt based on what it finds. The agent is goal-seeking and autonomous. You define the what; the agent defines the how.

This makes agents natively data-centric. They don't need — and are actually constrained by — activity-centric process descriptions. What they need is precisely a description of the data transformation they're expected to perform: what inputs are available, what output is required, and what quality criteria that output must meet. Everything else is the agent's problem to solve.

This also means the human-to-machine boundary will shift faster and more continuously than ever before. Traditional automation required massive engineering effort per process step and could only handle well-understood, rule-based work. Agents can handle unstructured inputs, ambiguous cases, and judgment-intensive work — and the cost of substitution drops by orders of magnitude. As models improve, transformations that required human judgment last quarter become automatable this quarter.

This creates a practical need that didn't previously exist: a process representation that is genuinely executor-independent, that describes what must be achieved rather than how or by whom, and that remains stable as the assignment of steps to humans, agents, or hybrids changes continuously.

An intellectual lineage

The idea of data-centric process modelling isn't new — IBM Research explored it through their "business artifacts" work starting in 2003, and the academic BPM community has built on it since. But the approaches were formally complex and never found a compelling practical reason to displace activity-centric thinking. I think agentic AI is that reason.

Processes as data transformations

Rather than describing processes by the activities people perform, I think we should describe them by the data transformations that occur. At any point in a business process, certain data exists in a certain state. Something transforms it into the next state. The process is that sequence of transformations, defined by inputs, outputs, and quality criteria for those outputs.

This is deliberately simpler than the formal approaches that have come before. I'm not proposing a new notation or meta-model. I'm proposing a lens — a way of looking at processes that makes them legible to both humans and agents, without the formal complexity that limited earlier data-centric approaches.

Executor independence. A transformation is defined as: given these inputs, produce an output meeting these criteria. Whether a human or an AI agent performs it — and how they go about it — is a separate decision. The process description remains stable even as executors change.

Natural observability. You don't need to instrument how people work — you observe the data artefacts that already exist in your systems. What data existed before a transformation, what exists after. This helps address a practical asymmetry: you can instrument agent behaviour in fine detail (they're software), but you can't easily observe human reasoning without turning every action into a form-filling exercise. Data-centric observation works for both.

Reuse becomes visible. When you describe transformations by their input-output specs, you start to see that different business lines are often performing the same transformations on similar data. Activity-centric descriptions tend to hide this. Data-centric descriptions surface it.

Testable agent substitution. The question shifts from "can an agent do this job?" to "can an agent perform this transformation to spec?" Give the agent the same inputs, check the outputs against the same quality criteria. If yes, shift the assignment. If not, you know precisely which criteria it falls short on — that's an actionable engineering problem, not a philosophical debate about AI readiness. And as models improve, you retest. The boundary shifts naturally and measurably.

Enabling genuine transformation. When you see the process as data states, you can ask: are these the right states? Is this intermediate data object only needed because of how humans cognitively approach the work, rather than because the process requires it? An agent performing a credit risk assessment doesn't need someone to first "spread the financials" into a standardised template — it might produce a better assessment working directly from the raw source documents. These redesign questions never arise from activity-centric maps because they take the current sequence as given. A data-centric view lets you ask what the process should be, not just who should do what it already is.

Starting practically

This does not require a comprehensive mapping exercise — and it should not become one. For any given process, identify the 5-10 major data states and the transformations between them. Define input-output specs and quality criteria for each transformation. That's days of work per process, not months.

Then ask, for each transformation: can an agent do this today? Partially? Not yet? Where it can, you have your first candidates for agent deployment — with clear specs for what the agent needs to achieve. Where it can't yet, you know precisely what's missing and can track when capability catches up. You've created a transformation roadmap grounded in data reality rather than activity-level guesswork.

Over time, as you apply this across processes, common transformations emerge — your highest-value reuse and automation opportunities. The data-centric process model becomes a living architecture asset that evolves as the human-agent boundary shifts. It's the minimum structure needed to make agentic transformation systematic, without the overhead that made earlier approaches impractical.

The academic foundations were right. The timing — and the need for pragmatism over formalism — is what was missing.

This section expands on ideas first published in a LinkedIn post on data-centric process modelling for agentic transformation. The concept of data-centric process modelling draws on IBM Research's "business artifacts" work (2003) and subsequent academic BPM research, applied here to the practical problem of agentic transformation in banking.