Process Flows Are Dead. Here’s What Replaces Them.

I've never cared for "as-is" process flows and now "to-be" flows should go away too. I've outlined what I think is needed as we define the future through Agentic Applications.

I had a spirited conversation recently that reminded me of something I’ve believed for years: “as-is” process flows are a waste of time. With agentic applications, I’d argue “to-be” flows are now just as obsolete.

Go back to when cloud-based enterprise applications first came out. What made it genuinely innovative at the time was that I was capable of showing a client a future-state process built on predefined business processes, designed from experience across the industry rather than from that client’s own history. What a client had done in the past was relevant to a degree. It revealed their industry, scale, and regulatory environment. But it was never the blueprint. The whole point was that you weren’t there to recreate someone’s legacy process in a new system with a nicer interface.

I’ve spent a good chunk of my career cleaning up projects where that’s exactly what happened anyway. A systems integrator runs as-is workshops, maps the current process in exhaustive detail, and then quietly rebuilds that same process in the new system because it’s the path of least resistance. It happens most often when the SI is leaning on the client’s own internal resources to define the future state, and those resources have spent years inside one way of working. Ask someone who has run the same process for a decade to imagine a fundamentally different one, and you’ll usually get the same process back with new field names. Nobody guided them to the right solution. They got handed a mirror instead.

Those projects don’t fail immediately. They fail over the next year or two, and then someone calls in an optimization engagement to fix what should have been designed correctly the first time. I’ve been on the other side of that call more than once. The as-is flow wasn’t a neutral documentation exercise in those projects. It was the mechanism that let a legacy process survive the migration in disguise.

Why I’ve Never Liked As-Is Flows

The projects I’ve had to clean up are the evidence, not a theory. Three or four weeks documenting a broken thing does the opposite of what it’s supposed to do. Everyone in the room, including the client’s own people, walks out with that broken thing loaded into their head as the reference point for what you’re changing. You’ve anchored the team to the paradigm you were trying to leave before you’ve shown them what the application can actually do.

That was already true before AI. Agentic applications just handed me the rest of the argument. But that only holds if we approach agentic deployments differently than we approached cloud. Get this wrong and you’ve built a newer version of the same trap, legacy thinking wrapped in agents instead of screens.

What Agentic Applications Actually Changed

I wrote about this when Oracle launched Agentic Applications at AI World London this spring. The framing they used is systems of record versus systems of outcomes. A system of record follows fixed rules, records what happened, and waits for a person to act on what it retrieves. A system of outcomes works toward an objective and acts on its own, inside the same security and data boundaries as the system of record underneath it.

That’s not a feature description. It’s an architectural admission about what the old model actually was. A system of record relies on predefined rules and paths, because the system and the people using it need the next valid action specified in advance. A system of outcomes can reason toward an objective within defined constraints instead, which means more of that path gets determined at runtime rather than designed ahead of it.

This is where the argument stops being abstract for me. When the system itself is built to run toward an objective instead of waiting to be operated, mapping the steps of the old process isn’t just extra work. You’re documenting the exact thing the new architecture was built to stop requiring. That’s the difference between as-is mapping being wasteful and as-is mapping being actively backward.

The Predefined Path Was the Workaround

A quick precision check first, because the easy version of this doesn’t hold up. It’s tempting to say process only ever existed because the executor couldn’t reason. A physician can reason and healthcare still runs on process. A judge can reason and courts still run on procedure. A pilot can reason and aviation still runs on checklists. Those exist for coordination, repeatability, evidence, and separation of duties, not because anyone involved can’t think.

The real distinction is three things traditional process design collapses into one artifact: the outcome, what has to become true, the constraints, what must or must not happen for legal, safety, or audit reasons, and the execution path, the specific sequence chosen in a given case. Traditional design treats the execution path as the primary artifact. Agentic systems make the outcome and its constraints primary instead, and leave the path to get worked out at runtime.

Payroll still calculates before it pays. A termination still follows certain steps for legal defensibility. Those are constraints, not blueprints, and they stay exactly as rigid as they’ve always been. Everywhere else, the sequence was never the point.

Guardrails survive. Blueprints don’t.

The Industry Already Said This. We Just Didn’t Listen the First Time

I’m not the first person to make some version of this argument, and I think that’s worth saying out loud instead of pretending otherwise. Michael Hammer, who effectively founded business process reengineering in 1990 with his Harvard Business Review article “Reengineering Work: Don’t Automate, Obliterate,” built his entire thesis around a phrase that still holds up: don’t automate, obliterate. His point was that companies rolling out early enterprise systems were making a specific mistake, digitizing the existing broken process instead of asking whether the process should exist in that shape at all.

That idea mostly didn’t happen the way Hammer meant it to. The technology was only part of the limitation. ERP systems still needed to be configured around deterministic logic. Organizational risk, implementation incentives, and consulting economics all pulled teams back toward recognizable workflows too. “Reengineering” quietly became “map the current process, then map a slightly better version of the same process.” The tooling forced business process reengineering to become the thing it was invented to argue against.

The Replacement: An Outcome-Control-Authority Model

If you’re not mapping steps, what do you actually hand a client instead of a process map? “Define outcomes” isn’t a deliverable on its own. It’s a slogan until someone tells you what the artifact actually looks like.

I developed a model for how I intend to approach this work going forward, knowing it will continue to evolve. For today’s purpose, I’ll call it the Outcome-Control-Authority model, OCA for short. Its emphasis on managing toward outcomes rather than prescribing a method was influenced in part by Kate Vitasek’s 2023 Forbes article, “Outcome-Based Management: What It Is, Why It Matters And How To Make It Happen”. That piece wasn’t written with AI in mind. It’s about managing people and vendor relationships around outcomes instead of process control, but the underlying logic resonated with me. Now, in the age of AI and agentic apps focused on outcomes, we’d outline one record per business outcome instead of one flowchart per process.

The three names in the acronym are layers, not a literal list of the eight fields underneath them. Here’s how they nest:

Outcome — what has to become true, and what could change the answer

• Outcome: What must become true?

• Context: What information may alter the response?

Control — the guardrails a client actually has to build against

• Guardrails: What must or must not happen?

• Escalation: When must control transfer to a human or another system?

• Evidence: What must be recorded to explain and defend the result?

• Evaluation: How will quality, safety, and continued fitness be measured?

Authority — who decides, and who answers for it

• Authority: What may the agent decide or execute?

• Accountability: Which human or organizational role owns the result?

Eight fields, three layers, one page, one outcome. Compare that to a forty-box swimlane and tell me which one a new hire could actually use six months from now.

A few of these are doing different jobs, worth separating out.

Outcome and Context redefine the design workshop, not just the process map. The old workshop spent most of its time getting a room to agree on steps. This one spends its time getting a room to agree on what “good” looks like and what information should be allowed to change the answer. That’s the harder conversation, and it’s the one that was always getting avoided by mapping steps instead.

The Control layer is what becomes configuration. This is the layer that turns directly into the build: approval thresholds, dollar limits, agent permissions, what triggers a handoff, what gets logged, how you’ll know later if it’s still working. The things that used to live in a decision diamond now live as parameters an implementation team can build against.

Escalation is where testers should spend their time. A test plan that only covers the happy path tested the ten percent of the outcome that was never going to be hard. Derive scenarios from it instead: what triggers it, what happens when it fires, whether the human on the other end actually has what they need to decide.

Evidence is the audit trail. An auditor needs to know who owned it if it was wrong and what got logged along the way, which is a different question than “did they follow the process.”

Evaluation is the field most projects skip, and it’s the one that keeps the rest honest. A process map never asked whether it was still working. An OCA record should get revisited the way you’d revisit a KPI, not filed away the day the project closes.

The Authority layer is the decision itself, and who answers for it. That’s the piece I want to come back to after walking through some real outcomes, because “who’s accountable” is the part almost nobody has actually answered.

That’s the completed artifact. Not a diagram. A page, per outcome, that a consultant fills out with the client, an implementation team builds against, a tester interrogates row by row, and an auditor can actually read.

OCA in Practice: A Few HCM Outcomes

A framework only earns its keep if it survives contact with real decisions, and a few of these need to be split apart rather than treated as one bucket, or you end up implying more automation than I actually mean.

Compensation isn’t one outcome, it’s multiple. Executing an approved change is structured, an agent can check for conflicts and walk a manager through submitting it inside existing approval rules and guardrails. The amount isn’t the agent’s call. Providing guidance, facts, and prompts throughout the submission is.

Recommending a change or finding someone who is due or behind where they should be is partly structured. An agent can surface market data or peer positioning, but the manager still picks the number. Deciding how merit or equity gets allocated across a whole team is a different animal. Budget visibility is structured enough to hand to an agent. The allocation decision is where I don’t think it should be yet.

Collapse those three into “compensation” and you end up sounding like you’re advocating for automated pay decisions generally, which isn’t the argument.

Benefits splits the same way. Enrollment execution, eligibility rules, contribution limits, plan restrictions, is structured enough for full agent autonomy, and it’s the easiest of these to get right because the boundaries are already coded into plan design.

Personalized plan recommendation, which plan actually fits my situation, is a different outcome with real financial and health consequences. That doesn’t mean it’s off limits. An agent can do this well, but it needs tighter guardrails than enrollment does: the reasoning behind a recommendation should be explainable, the employee should always see the option to talk to a person instead, and the agent should flag rather than resolve the genuinely ambiguous cases, a major life event, a complex family situation, on its own.

Involuntary termination is the clearest test of the model. It’s not that termination decisions are unstructured. The inputs and procedure around one are often highly structured: documentation requirements, review steps, legal sign-off. What stays human is the judgment itself, not the process around it. Authority: none for the decision. Escalation: always. Accountability: human, entirely, no matter how good the model gets.

The pattern across these: the Outcome field barely changes from client to client, most companies want roughly the same things to be true. What needs a consultant’s judgment is getting granular enough within an outcome that you’re not accidentally licensing more automation than you intended. That’s the real design work now. Not the box. The boundary, drawn precisely enough that nobody misreads it.

Accountability is the field I want to answer more directly than I have so far, because raising a question without an answer isn’t much of a contribution. A workable accountability model splits it into six roles instead of one. A business owner, who owns the intended outcome and the risk accepted in pursuing it. A policy owner, who owns the rules and guardrails themselves. An agent owner, who owns configuration, tools, and operational performance. A data owner, who owns data quality and permitted use. A human decision-maker, who owns anything explicitly reserved for a person. A control owner, who owns monitoring, testing, and whether escalation is actually working.

Here’s the point of splitting it this way: an agent should never be treated as the accountable party. Accountability stays with the humans and institutions that authorized its scope, defined its controls, and keep operating it. “The agent decided” isn’t an answer when something goes wrong. It’s a redirect. The real question is always which of those six roles failed to do their job, and that’s answerable in a way “the AI made a mistake” never was.

The New Documentation Isn’t a Diagram

Here’s the part of this I think is the most direct proof of the whole argument, and it’s easy to miss underneath the protocol names. Agent2Agent, or A2A, introduced by Google in April 2025 and later donated to the Linux Foundation, doesn’t just let two agents exchange a message. It lets an agent discover and call on another agent’s help at runtime, selecting from whatever capabilities have been made available to it, without a human pre-wiring that specific connection into an integration diagram in advance. Nobody has to predefine every situation in which a finance agent should call a sourcing agent, or hardcode every valid sequence between them. The agents select among approved, discoverable capabilities at runtime instead.

That’s the outcomes argument happening at the level of enterprise integration architecture, not just inside one agent’s task list. What used to get drawn as a fixed diagram, which system talks to which, in what sequence, is becoming something agents work out for themselves the same way they work out their own steps. The execution path isn’t just moving out of a single agent’s design document. The integration diagram doesn’t disappear, but its job changes: instead of predicting every valid sequence in advance, it shows capabilities, boundaries, trust relationships, and controls.

Model Context Protocol, from Anthropic, splits cleanly from A2A underneath this. At a simplified level, MCP exposes tools, resources, and context to an agent, while A2A supports collaboration and delegation between agents. In practice both get used together, an orchestrator delegates through A2A while each specialist reaches its own tools through MCP.

The part I think is actually the better metaphor for this whole piece is the Agent Card. When an agent is built to work with A2A, it publishes a card, structured metadata describing what it can do and how to reach it, so another agent can discover its capabilities without a human wiring up an integration by hand. That’s what makes the runtime agent-calling-agent behavior possible in the first place. It’s not a picture of steps. It’s a declaration of capability and boundaries.

Even here, old habits die hard. I’ve seen people trying to document multi-agent systems by reaching straight back for BPMN, swimlanes with an agent lane instead of a person lane, gateways routing high-confidence cases to auto-resolution and low-confidence cases to a human. I get the instinct. But it’s an awkward fit, because the entire value of an agent that can call another agent on its own is handling the branches nobody thought to draw in the first place.

Change Management Was the Right Instinct All Along

This is where I think the piece closes the loop on where it started. If there’s no fixed process to train people on, change management can’t be “here are the new steps.” It has to be “here’s what you’re accountable for, and here’s what you no longer need to hold in your head.” That’s a genuinely different conversation with a workforce, and it’s the one I think most transformation programs still aren’t having.

The as-is flow was never really about documentation. It was a stand-in for that harder conversation, what does this person actually need to be able to do. Skip the flow, and you don’t skip the work. That’s the part of “systems of outcomes” nobody has put in in a keynote yet. Hopefully by the end of this you’ve seen my blueprint for how the agentic application deliverables change and how the conversations with the workforce need to change.

P.S. And if you know me, please don’t ever get me started on my opinion on “click-by-click navigation guides.”