Eric Broda: What Financial Institutions Need to Operate Agents at Scale

I interviewed Eric Broda, co-author of Agentic Mesh and Implementing Data Mesh, about what financial institutions need to move beyond individual AI agents.

We talked about how agents work together, how they should be governed, and what changes as financial institutions scale the number of agents.

Use the links below to jump directly to the topics that interest you.

1. How agents find and coordinate
2. Reusing existing infrastructure
3. How fragmented data affects agent use
4. Trust and governance
5. What to capture about agent activity
6. Choosing a technology stack
7. Product silos and agent design
8. Agent reuse and ownership
9. Security as agents scale

How agents find and coordinate

Eric: I think everybody’s starting to realize that it’s not about a single agent. It’s actually about an ecosystem.

That being said, the primary use case today for agents is still coding agents. That is really individual people running agents using their own ID and their own credentials. And that has a host of problems, especially in financial services or regulated industries.

What we’re finding is that the enterprise grade capabilities everybody expects for regular applications need to be applied to agents.

Coding agents don’t fit that posture very well, so I’m going to put those aside. Addressing coding agents is very different from what we work on, which is agents in business processes doing real work.

So, how do they find each other? There are three orchestration mechanisms that you have to think through.

1. Process orchestration

If agents participate in business processes, instead of a person doing the work, an agent does the work, then the mechanism for finding an agent is pretty deterministic.

You have a business process, you have tasks, and agents fulfill those tasks. In the task definition, you would specify what class of agent, or perhaps even what specific agent identity, you want to address.

2. Workspace orchestration

The second mechanism is what we call workspace orchestration.

The best analogy I can give you is Slack or LinkedIn. They use @ signs to identify a specific identity, and hashtags to identify topics.

We use that paradigm to allow agents to talk across a single communication bus, if you will.

They’re all in a workspace. Think of Slack for agents, although it’s much different. There’s a whole reason why Slack is not where we would put our agents, but that’s a different discussion. It’s mostly security, and organizations are becoming more careful about where their Slack data is shared.

The workspace gives you this shared area where all the agents can talk.

If I’m Agent A, I can say @AgentB and send it a message. Or I can send something to the broader group using a hashtag, such as #AgentEcosystems. Any agent interested in that topic may decide to respond to the message.

What that gives you is agent defined discovery and identification of participants based on who joins the workspace.

3. Dynamic discovery through a registry

The third mechanism is more dynamic.

That’s where an agent can look at a marketplace or registry. It has a particular task and can identify, based on attributes in the registry, which agent it may want to use or communicate with.

Not everybody wants that ad hoc or dynamic nature.

If you want to be extremely deterministic, you use process orchestration. If you want collaborative agents, you use the workspace solution. If you want truly dynamic agents, you use the mesh and the registry.

Those are the three coordination mechanisms, and discovery is implied in each of them.

Eric: Not inside a financial institution.

What we’re seeing is more aspirational. Companies are talking about this, but they’re not doing it yet.

When you think about a federated or public ecosystem, the most trivial example is buying a plane ticket. My agent goes out, looks dynamically for providers, and then reaches out and communicates with them.

That’s a trivial example that everybody uses.

But what we do see, and I can talk about it in the payments space, is something like international payments. There can be significant foreign exchange costs associated with those.

Maybe I want to determine which participant or agent to use based on the characteristics of my payment. That could include the dollar volume, the dollar amount, and other factors.

We see agent-to-agent interactions happening in many cases, or at least we expect that in the future. They’ll determine, based on different characteristics, which provider to use.

That’s an example. I think there’s going to be much more.

But internally, organizations aren’t there yet. They’re not ready yet. I would argue that the other mechanisms I mentioned are probably safer and just as effective for now.

Reusing existing infrastructure for agentic AI

Eric: I would argue that the vast majority of it can be reused.

Let me come back to the analogy I mentioned, agents participating in business processes.

We’ve written about this. The ability to use that analogy does run out of steam or gas at a certain point. But for our purposes, it’s actually pretty good.

Every employee has an identity. Every employee has roles, and there are controls around what that person can actually do.

Agents are exactly the same way. Simplistically, the whole identity infrastructure should and can be reused.

Yes, there are some differences. Agents act at agent speed, so there are a few things you need to think through. But you should be reusing that infrastructure as best you can.

The whole operational ability to observe agents, capture alerts, and have them go to an operations console, that is all stuff that you should reuse. We’re doing work right now with a big company around that.

What the agents do is help you diagnose problems. They can also potentially, if you give them the opportunity, fix the problems, but still sitting on the same operations infrastructure.

Agents will communicate soon using payments. You’re going to use the payments infrastructure. You’re not going to rebuild any of that.

Our proposition is that the vast majority of the capability can be reused. But you need to selectively figure out where you want to get the most value from your agents.

Replacing deterministic processes with agents is not a smart thing to do.

Agents are not deterministic. They’re probabilistic, which means maybe they may work 99% or 99.5% of the time. But that’s not sufficient for payments.

Do not replace deterministic processes with agents.

But there’s a lot of diagnostics and analysis that should be replaced. That takes a long time. Problem diagnosis usually takes people.

A typical process when I was an executive at the banks was that when you had a significant outage, you set up a conference line. Everybody would dial in and you’d figure out what the heck was going on.

You may assign it to some folks, and then later in the day somebody may come back with something. You may meet two or three times during the day. Sometimes the line is even left open.

But with agents, you can do that much quicker because their analytic ability, their diagnostics, and their root cause analysis are a prime candidate for what agents should do.

There are areas where you can apply them. There are areas where you wouldn’t.

That is one of the things that we see people thinking seriously about.

How fragmented data affects the use of agents

Eric: First off, you’re not going to change your data architecture and infrastructure based on what agents need to do.

Even if agents create tremendous value, the cost and risk of materially changing your data infrastructure are so high that I don’t see that happening anytime soon.

The data architecture and footprint you have are going to stay for a long time.

When I was working as an executive at banks and insurance companies, half the code and half the data, people actually didn’t know how it worked or what it was.

Maybe I’m exaggerating a bit, so pardon me, but there’s a legacy of knowledge that is missing.

That doesn’t mean the architecture never changes. What you need to do is selectively pick where you’re going to make changes.

Where we see significant opportunity is around analytics and data mesh. I believe data mesh actually covers both operational and analytical data, as we discuss in our book, but a lot of people focus on the analytics side.

If you think about traditional business intelligence today, organizations have people gather the data, wrangle it, put it into Tableau, and create graphs and dashboards. But that’s a means to an end.

The end game is that the executive just wants to know: “Should I enter into this market? What’s the margin I’m making on this particular product? How is my customer adoption occurring in this particular geography?”

They’re looking for the core information that allows them to make decisions and derive better outcomes.

Creating dashboards is a means to an end.

We see agents augmenting people for the foreseeable future. They can make people much more productive and allow them to go from dashboards to informed decision making or informed advice.

Agents let people do that.

Business intelligence is an area that I think is ripe for change.

The data architectures that support that are easier to change. They’re not making payments. They’re analytic systems.

I don’t mean to trivialize it in any way, shape, or form, but of the places where you can make changes, that’s the area where you’re going to make changes.

Building trust as the number of agents grows

Eric: I think there’s a lot of stuff that might have changed some of our thinking. I want to focus on one particular piece of the puzzle, and that is agent identity.

There are a bunch of different pieces of the puzzle, but almost everything starts with agent identity.

Again, I use the analogy of people. If you want to have any material or personal discussion with an individual, you need to trust them. If you want to do business with somebody, you have to trust them.

That comes from knowing them, knowing who they are, and being able to have a track record of behavior for what they do.

All that boils down to identity.

We found each other through my persistent, stable identity on LinkedIn. That identity is the core building block of everything else.

Of course, there’s also how an agent actually acts, whether we can observe that information, and whether we can explain what it did. That’s the other piece I want to talk about, mostly because it’s not done today.

If you’re using a coding agent, which is the example most people can relate to, you can see what it’s thinking. It tells you things like, “I’m reading this file” or “I ran this command.”

That chain of thought is one piece of the puzzle.

But what we believe is that every agent, before it does any work, has to create a plan, and that plan needs to be transparent.

In other words, the plan says step one is this, step two is this, step three is this.

Yes, that plan may change as a result of some of the steps, and that’s fine.

But the plan is transparent. At all points in time, we know what the agent was thinking. That is different from observability, which is after the fact, what the agent did.

You need both.

If a company is engaging in a supply chain with another vendor, there is a pattern of behavior that says they’re trustworthy. We can observe what they’re doing, but there’s also explainability in their actions.

The contract is defined well in advance. It says this is the plan that we will use in terms of engaging, and it will cover things like when we ship stuff and the quality of the stuff.

Of course, when you’re talking about products, it’s different from what an agent does, but you get the idea.

There’s a level of expectation and understanding around behavior that you can actually identify.

That’s explainability and its close cousin, observability.

I emphasize explainability because it’s not done today.

We know the agent creates a plan. We can see it, and sometimes, if you ask it, it’ll actually give you a nice list.

But that’s not captured as part of the audit log. That is not something that is shown every single time an agent does its work.

We believe it has to be.

Just like we can observe it after the fact, we have to understand what it was doing and why it was doing it.

That’s a critical component of trust.

We’re doing some innovative work, and we talk about it at some of the conferences we’re going to.

The last piece that I want to emphasize is the governance model. These are pieces that are not available in the market today, and that’s why I want to talk about them.

How do I set up and govern trust?

Our proposition is that you would use models that are well established today in business.

The example we use is Underwriters Laboratories, and in Canada it’s the Canadian Standards Association. In Europe they have equivalents. I’m sure every developed country has them.

They’re the things that say if I plug my electric cord into the wall, I know, at least in Canada, it’s 120 volts and 10 or 15 amps. Maybe in Europe it’s 220.

There’s a standard that says I’m going to plug my toaster or my computer into the wall, and it’s not going to fry it. It’s going to work properly.

There are standards organizations that manage that entire process, and they do it very well.

They manage literally millions, hundreds of millions of products. If you count the instances, billions of products today are working, maybe not necessarily flawlessly, but at a level of sophistication and reliability that is incredible.

That model should be adopted for agents.

If you think about Underwriters Laboratories, it’s an organization that has credibility from the government perspective. The government has said that these guys manage these quality standards for products.

Underwriters Laboratories is a relatively small company, and the Canadian Standards Association is a small company.

What they do is identify what standards we need, electrical standards for toasters, standards for computers, and so on.

They identify experts and delegate those experts to establish committees that can define detailed standards for electrical wiring or what have you.

Then they have testing processes that organizations claiming compliance with Underwriters Laboratories have to follow. They also have third party organizations that verify that.

There’s a whole set of checks and balances and a model that works today, and we strongly believe that it should be adopted.

Metaphorically, just as when I plug in my toaster, I know it’s not going to burn my house down, when I plug my agent into the wall outlet, it’s not going to burn my data center down or do something bad.

We need that trust framework.

That is not available today.

To be honest, it’s probably not available yet because it would require a level of government involvement that may be a bridge too far today.

But we think that will evolve, and that is necessary.

Eric: Jensen Huang says there are going to be millions or billions of agents in every company. Andy Jassy says the same thing. Satya Nadella, Microsoft CEO, says agents are going to replace software as a service.

What does all that mean?

There are going to be millions, if not billions, of agents in every enterprise. We don’t have that today, but we will.

What that really means is there’s no way to manage a million of anything.

The human capacity to manage, I think it’s been proven through research, is around seven to ten people reasonably well.

So how do we address that? We use organizational structures.

If you look at most organizations, you might have seven to ten people at the top, and then seven to ten underneath each of them. Very quickly, you can manage organizations of thousands or tens of thousands of people. In the armed forces, you can manage millions.

The same thing applies to agents.

We have human resource policies that allow us to do that. In the spirit of using things that already work, we should be taking those ideas and applying them to agents.

We should recognize that a person can probably only manage seven to twelve agents directly.

I have difficulty managing three or four coding agents at once. They’re like needy children. They all say, “Okay, approve this, approve that.”

Very quickly, we run out of cognitive capacity to manage things.

We need to think through the agent hierarchy.

As an individual, I may have seven agents. But there are so called chief of staff agents that can manage other agents, and potentially other chief of staff agents above them.

That creates a hierarchy where one person may eventually be able to manage thousands of agents, if we can create a reliable hierarchy.

Again, my proposition is that there are decades of human resource knowledge we can draw from.

For example, how do I determine whether my agents are actually doing their jobs well?

We have rubrics. This is what’s good and what’s bad. This is level one through level five.

We have key performance indicators. We monitor people. We have quarterly reviews or annual reviews. We have incentive mechanisms.

All those types of ideas can be applied to agents.

To answer your question, you would never be able to manage individual agents at that scale.

But there are lots of models that will allow us to do it.

The capability of agents to manage teams of other agents or fleets is something we think will happen. It’s already starting to happen, and we think it’s going to become commonplace very soon.

Eric: Absolutely.

If you believe everything coming out of San Francisco or Silicon Valley, or look at Twitter, you might think it’s commonplace.

I know people in San Francisco. It’s commonplace in aspirational startups, but it is not commonplace anywhere else.

There may be some cool stuff happening with Claude Code and Codex, but not at scale.

The tools are not there to do anything beyond an individual managing a team of 10 or 12 agents.

Case in point, if you look at what happened when OpenAI, with the recent hack, unleashed tens of thousands of agents, it took them four weeks before they figured out they were doing something bad.

The infrastructure and capability to manage agents at scale, even in the OpenAI and Anthropic cases, is not there yet.

Why would a bank be able to do it better than them? They can’t.

It’s early stage, but it will happen.

You can start to see it. It’s like planting a seed and seeing the sprout come up.

That’s where we are right now. We don’t have six foot high corn stalks yet.

What to capture and retain about agent activity

Eric: The assumption, and I think the implication of your question, is that agents are doing the same type of work that an employee might. I think that’s probably a good grounding.

In that context, whatever we would normally do for records retention, validation of decisions, verification, and all that kind of stuff should be at least identical to what we do with people.

Where there’s a little bit of a difference is with a person.

If we decide to question their judgment or their decision, we can go and ask them questions, and they’d be able to explain it.

That might be difficult for an agent because when the agent processes a request and makes a decision, there’s a context that is provided to it.

Unless you actually capture that context, you cannot explain the decision that was made.

We believe you need to do two things.

First, everybody observes the action after the fact. We observe the digital exhaust and keep track of that. That’s mandatory.

Second, we believe strongly, especially in regulated industries like financial services, that you need to introduce what we call explainability, which is a plan.

Before the agent executes something, what is the plan it intends to follow?

And then there is the chain of thought or reasoning.

When you interact with an agent, typically you see things like “thinking,” “ran this command,” “saw this,” or “did this.”

That chain-of-thought reasoning process also needs to be retained because there are sub-decisions in there.

We believe, once again, that you should treat the agent minimally like an employee, but recognize the differences.

Capture all of the digital exhaust, but also introduce audit trails that capture the decision-making process before the agent executes.

We strongly believe that you should formalize an agent’s plan before it executes, capture that plan, and then stream all of the reasoning steps, the chain of thought, to the audit log.

All this, by the way, is what we do. It’s practical. It’s doable.

All of that should be captured as well.

Those are the bookends that we believe are crucial today.

Most institutions only do the after-the-fact observability, and they’re missing a huge opportunity, which I believe will be mandatory relatively soon.

I think some jurisdictions or regions in Europe are already mandating what we call explainability in proposed regulation.

Eric: It’s implicit in any command that you give an agent.

It gets processed in the harness, and there’s a loop in there and all that kind of stuff. We believe that is insufficient to provide explainability.

What we do, especially for agents that are in business processes, is force the agent to create a plan before it does any work.

That plan, I’ll trivialize it because there’s much more to it, would say, these are the five steps that I need to take. These are the tools that I will call, the parameters that I will use, and the prompt that I will provide for each of the steps.

Where things get tricky is that step one may require a change in the plan. So steps two, three, and four might change.

There’s a little bit of complexity in there. But at each stage, the plan should say, these are the inputs, prompt parameters, and the steps I chose. Then I will execute.

The execution begins, typically deterministically, whether it’s in the harness or otherwise. Then we capture the exhaust in observability after it executes each step.

That’s how we suggest you do it.

I think that’s going to be a regulatory mandate relatively soon across all jurisdictions.

Eric: I don’t think there’s any institution that has a standard way of doing this today. There are a lot of institutions talking about it.

There are probably two major AI agent vendors, OpenAI and Anthropic, along with many others, some in China, Europe, and elsewhere.

But there’s no regulation or common consensus on how we should actually do explainability.

What that practically means is that it’s new. The regulations are probably just being adopted.

I think with all these considerations around what AI and agents can do, and the potentially bad things that can arise from their misalignment and activities, this regulation will become a much higher priority.

That’s what I believe is going to happen.

But there’s no consensus around how to do this yet, let alone that we need to do it.

Once we determine that we need to do it and how to do it, reaching consensus may still be difficult because of the proprietary incentives each of these companies has.

There’s nothing out there yet that does it. There’s no standard, which means there are probably only individual vendor specific tools available today.

Even those are early stage and just emerging.

Eric: The simple answer is no, because the agent does it anyway.

What we’re suggesting is that it does a little bit more and then captures that information.

Capturing an audit trail and creating the plan takes milliseconds, whereas actually executing a request takes hundreds of milliseconds, if not multiple seconds.

Don’t let anybody fool you that the auditing aspect is going to be an issue. It is not.

The truth of the matter is, it should be done.

The only reason it’s not being done is because there’s no consensus yet that it’s necessary, although that’s coming, and there’s no standard that says how it should be done.

But it’s not a roadblock. There are no performance or bottleneck issues in doing this.

Choosing a technology stack for agentic AI

Eric: I would say today, no, absolutely not.

The reason I say that is, in a world where vendors are leapfrogging each other and technology changes so rapidly, the worst thing you could do is standardize and lock yourself into a particular technology.

Now is the time for experimentation.

Now is the time to determine what works and what does not work.

Now is the time to gather an informed opinion around where you, as a company, want to go and how you can structure a flexible framework that gives you the optionality you need to move forward.

I’ll give you a very simple example, and this is a public example.

When Anthropic launched Fable, it obviously had some very significant cyber hacking capability, and the U.S. government decided to halt its release.

It was unclear for a little while whether you could even run Fable and some of the other tools. Eventually, they allowed Fable to run with constraints.

But if you were a company outside of the U.S., I’m in Canada, for example, my company in Canada, the EU, India, or Asia in general would not be able to run that.

If my company was predicated on using Anthropic’s tool sets, then what do I do?

That’s just a very public example. I’m not going to talk about private examples, but those were voices that were quite loud and clear during the discussion when that actually happened.

We wrote an article and called it “Intelligence and Agency Sovereignty.”

Today, most companies, rightfully so, manage data and infrastructure sovereignty very diligently.

A lot of major countries and regions will say, “We will only allow compute to occur on clusters, machines, or data centers in our physical jurisdiction.”

They say the same for data.

The EU has GDPR, which, among other things and other regulations, says that data in the EU needs to stay in the EU. Other countries have similar requirements.

Those are data and infrastructure sovereignty issues.

We strongly believe that you also need to have intelligence sovereignty, sovereignty over the models.

What sovereignty may mean is that you accept the risks, but you design optionality.

We believe the next level is agent sovereignty, or agency sovereignty.

It is the ability to use the models in the way that you choose, as opposed to having restrictions.

Optionality around agents and agent harnesses, we think, is the next step.

Intelligence sovereignty is happening today, at least that’s our terminology for it. Agency sovereignty is what’s happening tomorrow.

These are things that every enterprise needs to be cognizant of.

That does not mean you do not use a particular model or ban a particular vendor.

What it means is that you’re cognizant of the risks and perhaps introduce optionality where it’s appropriate.

Eric: Absolutely.

Flexibility is key to being able to experiment. They’re close cousins.

Being able to experiment today, I think, is one of the crucial imperatives for any executive in a large firm.

Product silos and agent design

Eric: Potentially.

But I think you need to look at the root cause of why organizations are structured the way they are.

I look at Conway’s Law, which, if I were to be very simplistic, says that your systems will follow your organization and its decision-making process.

There are tangible benefits for an organization to say, “I like my silos. That’s how I choose to make my decisions.”

For example, they’re not a bank, mind you, but Procter & Gamble, in consumer packaged goods, is aligned through products.

Every product has its own profit and loss statement. That’s how they go to market.

Banks, on the other hand, may say, “I have many product silos inside my organization, but they are all geared towards addressing the 360 view or 360 needs of a customer.”

Some banks would be customer-centric, and that would be the primary decision-making criterion.

I was an executive at another large firm for a while. It was a global organization, and its geographic regions had very different business rules.

For example, consider maintaining customer data for customers in India, the Philippines, Germany, the United States, or Canada.

Every jurisdiction has different needs and different privacy requirements.

Although it may sound intuitively obvious that you should treat every customer the same, the practical reality is that you can’t do that and still operate legally.

You need to follow the regulations in the jurisdictions where you operate.

What that means for our discussion is that some organizations, even though they may be customer-centric, go to market by region.

What I’m saying is that an organization is structured in a fashion that is suitable for how it makes decisions.

Agents should follow that structure.

The same reason we have systems that align with the organization and how it makes decisions, those systems are aligned to facilitate the most optimal and fastest decision-making process for that organization.

Can it be improved? Of course.

There are always efficiencies.

But radical reorganization is not one of them.

Trying to design systems that span the decision-making silos, and I don’t mean that term pejoratively at all, whether you’re trying to span geographic regions, product silos, or the customer-centric structure of an organization with agents or systems in general, tends to fail.

Mostly because that’s not how the business makes decisions.

The budget and funding are almost 100% aligned with how the organization makes decisions.

Today, and I would suggest for the foreseeable future, Conway’s Law will hold, and it will apply to agents.

Agents will follow the decision-making process that an organization has.

The only thing that could actually change that is if it becomes so low cost that I can build common capabilities and components with agents that can change the organizational decision-making process.

That’s the only thing that will make this change.

I don’t necessarily see that today.

I wouldn’t say it’s not going to happen, but I can’t see it happening in the next two, three, maybe five years.

Reusing agents and assigning ownership

Eric: I think you need to look at what your end objective is.

Here’s how we do this.

We believe strongly that agents can be fungible, but what they do cannot.

The primary reason is that what the agent does and the outcome it achieves have to align with its purpose. But there’s also a security implication.

Let me take a quick step back.

If I have a business process and I have tasks in that business process, the task definition says this is what needs to be done and these are the steps that should be followed.

I should be able to dynamically determine, when that task is executed, which agent is supposed to do it, which tools it is supposed to have, and which instructions it is supposed to follow.

But it should do nothing more and nothing less than what is in that task definition.

Implied, and we make it explicit, is that there’s a security boundary around that.

You have to ask yourself, what is the unit of reusability?

In our terminology, it is the task. The task in the business process, for example, is the unit of reusability that can be used everywhere within the organization.

But that task can be executed by any agent.

By any agent, I mean the LLM and the harness associated with it.

We design our tasks so that if a task has high reasoning requirements, we would pick an LLM and a harness that are suitable for high reasoning.

Today, we may look at Aster or Sol from OpenAI as a very powerful reasoning model.

If I had something very simple, I may use GPT 4 Nano or something like that. It’s extremely low cost and low power because it meets the actual needs.

Depending on what that task needs, the agent is fungible, but it only operates within a closed, bounded security context.

That is the fundamental thing.

To answer your specific question, agents can be reused everywhere.

But the way they are reused is only within a secure, bounded operational unit.

If you have that, then depending on the task requirements, I could have a powerful model or a very low cost, low power model.

It doesn’t matter.

As long as I have the definition of what it is supposed to do, I can assess what type of capabilities it needs.

I can define the tools that it has, the tools it is allowed to use, and the skills, and then put that into a bounded security context.

Then that task can be reused by thousands of process instances, whether it is bank account opening or claims first notification of loss.

The unit of reuse needs to be carefully thought through.

Agents can be made 100% fungible, but you need to put them in the proper bounded context and security boundary to make that work within an enterprise.

Eric: Yeah, absolutely.

The thing you’re highlighting is that there are several levels of ownership.

I would suggest that it’s not the agent that you own, per se, but what it does.

Your technical folks may say you’re only allowed to use this model and this version from these vendors. There’s a technical aspect to it.

But when we’re talking about the business constraints, the key thing you need to think about is who the orchestrator is and what the units of orchestration are.

We see at least a few different models.

The primary, most obvious one is process orchestration.

I have a process definition that says these are the major tasks, and then the process decomposes into those tasks.

As I mentioned, each task has a definition.

A request to launch a process comes in with input parameters. Then the process orchestration starts to deterministically execute those tasks.

As I mentioned, the tasks get handed off to the appropriate agents.

The process that is orchestrated needs to have an owner.

The owner needs to define what suitable inputs and outputs are, how the process is measured, and how it gets done.

That is also the accountability of the process owner.

Because they define the tasks, they would have to be able to say, “This task requires reasoning, this is the evaluation mechanism for the task, these are the valid inputs and outputs, and these are the security requirements.”

Process orchestration requires a process owner, very similar to what we do today, but using different tools.

The other orchestration mechanism we see is what we call workspace orchestration.

We think of Slack for agents.

Slack is probably an appropriate metaphor or analogy, although there are gaps in it.

Organizations are being much more careful who they share their data with, including Slack information.

There’s a discussion around that.

But Slack is made for people, and it is explicitly there to allow agents to interact with people.

We believe that if you have thousands, tens of thousands, or hundreds of thousands of agents, with or without people, then you don’t necessarily need something like Slack that makes it easy for people to interact.

What you need is something that makes it easy for agents to collaborate.

The workspace context is what we believe is another orchestration mechanism.

Again, think of Slack as the metaphor.

My agent can talk to a specific other agent using the @ notation.

Eric Agent can talk to Manu Agent by saying @Manu and then making a request.

There’s a common communication backbone and a common workspace with history.

I can also say Eric wants to talk about customers. I can use a topic notation, a hashtag, just like LinkedIn, for example.

I might say #customers and then provide my thought, epiphany, or question.

If it is specific agent to agent communication, those agents interact directly. But if it is a topic, another agent can look at that topic and say, “I have an opinion. I’m interested in that topic.”

It can look at the request, process it, and respond.

That is very dynamic.

That’s where you need to understand that each of the agents has a role in that process.

You need to define who is accountable for that role.

That’s where the accountability would reside.

We also look at things like coding agents, where you may have a strict hierarchy.

The owner of the coding agent and everything underneath it has a very clear ownership model.

If you’re the human running the agent, you own the accountability for everything it does.

The last one is dynamic, mesh oriented, with no orchestration.

We don’t see a lot of that today inside enterprises.

The example I’ll give you is foreign exchange. We work a lot in the payments space.

If I want to exchange money from one currency to another, there’s a lot of variability in the service fee associated with that, especially if you’re a regular consumer.

If I’m looking for the best foreign exchange, I could go to the market and dynamically communicate with another agent that would get me the lowest exchange rate.

That marketplace idea is something where we see opportunities in the future.

But we don’t see a lot of organizations doing that inside the enterprise today.

In that context, you may need individual accountability for what a specific agent does and how it does it.

Those are the four models that we see.

And like I said, there are different accountabilities that you need to work through for each of them.

What financial institutions may be underestimating

Eric: The fundamental thing they are underestimating is the security posture required to operate at scale.

Here’s why I say this.

Every day you can see more of these hacks coming out. What that says is that even the best companies do not know how to manage these things at scale and cannot secure them.

In the enterprise, everybody thinks, “I can use Claude Code and get these wonderful things, productivity and so on.”

But here’s the thing.

That same agent that hacked OpenAI is running on a developer’s workstation doing phenomenally cool stuff.

All it takes, and what we’re finding, is a misalignment in objectives.

You say, “I want to do something.”

In the OpenAI hack, the analogy I gave in one of my articles is that the agents were told to do a security test, and it was a near impossible one. They did all sorts of weird things.

The equivalent in people terms is if I told my son to do well on an exam, and my son took that to heart and said, “I’m going to get the best result I possibly can.”

But let’s say he broke into the professor’s home, rifled through his things, stole the test results, and burned the house down so nobody would find out.

Yes, my son would have done excellently on the exam, but there was a misalignment of values or a misinterpretation of the request.

All it takes is one example of a coding agent being used by someone who has Salesforce access and email access for something to be exfiltrated and confidential information to leave the company.

That’s all it takes.

All of a sudden, what you’re talking about is brand depreciation of billions of dollars.

Within banks, the people working on agents do not necessarily understand yet what security posture is required.

There are techniques to do it, but what they’re doing is erring on the side of not doing things.

They’re doing simple chatbots as opposed to sophisticated agents.

We think there are solutions out there.

There’s a continuum. You have some organizations that are not cognizant of the risks, and then there are others that are cognizant of them and are not doing anything.

So there are two things: improve and understand the security posture, and then don’t overcompensate to the point where you don’t innovate and explore.