Introducing the Agent Factory

There is something about the traditional AI consulting model that feels increasingly backward to me.

A customer has a business process they think might be a good candidate for an AI agent, so they bring in a consultant. The consultant scopes it, writes a statement of work, estimates some hours, adds some contingency, and the customer starts paying. Then everybody begins the experiment together.

Can the agent actually do the job? Is the data accessible? Will the integrations work? Will the models be reliable enough in the real world, not just in a demo? Will the thing require so much model consumption that the economics become stupid? Nobody really knows yet, which is exactly why it is an experiment.

But for some reason, the customer usually funds that uncertainty.

If the experiment works, great. If it does not, the customer still paid the invoices.

That model made more sense when software development was mostly deterministic. You had requirements, developers wrote code against those requirements, and while projects certainly went sideways, the biggest unknown was generally how long everything would take and how much rework would be required. AI agents introduce a different kind of uncertainty because some questions simply cannot be answered completely from a whiteboard, a requirements document, or a proof-of-concept slide deck. Sometimes you have to build the thing and see whether it can actually perform the work well enough to matter.

Which made me wonder why the customer should automatically be the one paying to find that out.

That question is basically what led us to Agent Factory.

Bring us a process, not an AI strategy

I am not particularly interested in another conversation about somebody's “AI strategy.” Those conversations can go on forever, usually involving broad statements about transformation, productivity and competitive advantage without ever getting close enough to an actual business process to determine whether there is anything worth building.

I am much more interested in something somebody is doing today.

Maybe people review incoming requests and decide what happens next. Maybe they research information across several systems, compare documents, monitor something continuously, prepare recommendations, update records, route work, answer repetitive questions, or follow up with people. It could be taking one person five hours a week or ten people half their day. What matters is an identifiable process that consumes meaningful time, money, or capacity.

Once you have that, the conversation gets much more useful because only two questions matter at the beginning: can an agent realistically do this, and if so, is it actually worth doing?

Those are very different questions, and I think the AI industry has spent far too much time answering the first while conveniently ignoring the second. AI can technically do plenty of things that make absolutely no economic sense to automate, and other processes can have huge business value even when the technical work is relatively straightforward.

Development difficulty and business value are not the same thing.

We underwrite the idea first

With Agent Factory, our first job is not to sell you a development project. Our first job is to decide whether we think the idea deserves one.

We look at the process, how often it happens, how much human effort it involves, which systems are required, what data the agent would need, what integrations might be necessary, how much model consumption we expect, and what the resulting capability could realistically be worth. We are effectively underwriting the agent before we start building it.

Sometimes the answer will be no, and I think that is a feature rather than a failure.

The process may change too often. The underlying data may be a mess. A required system may not expose what we need. The models may not yet be reliable enough for the particular task. The consumption costs may destroy the economics. Or the whole idea may sound much better as an AI story than as a business case.

I would much rather discover that early than spend six months proving it with the customer's money.

And I say “yet” deliberately, because AI capability is moving quickly enough that something that does not make sense today may look very different six months from now. There is no particular value in forcing an agent into production before the technology or the economics are ready.

We agree on what success means before we build anything

AI projects can get fuzzy very quickly. Everybody leaves the kickoff meeting excited, development starts, the agent begins doing some impressive things, and somewhere along the way people lose sight of exactly what problem it was supposed to solve in the first place.

We want to avoid that, so before we invest in development, we agree on the capability itself. What does the agent receive? What does it evaluate? Which systems does it need to interact with? What actions does it take? What level of reliability, accuracy, or throughput is acceptable?

We also agree on what the subscription will cost if we successfully deliver that capability.

Not after we build it. Before.

That matters because both sides know exactly what the deal is from the beginning. If we make the agent work to the agreed standard, here is what the customer will pay. If we don't, the subscription doesn't start.

Pretty simple.

Then we take the development risk

For qualifying Agent Factory projects, Forceworks funds the development.

We don't send invoices while our engineers figure out whether the agent is viable. We take that risk. When we think the agent is ready, we test it against the criteria we agreed on at the beginning. If it meets those criteria, it goes into operation, and the subscription starts. If it doesn't, the subscription doesn't start.

That changes the incentives significantly.

Under the traditional consulting model, the consultant makes money while the project is being built, regardless of whether the final result creates enough value to justify what was spent. Under this model, we do not make money from the effort itself. We make money after we deliver a working capability the customer already agreed was worth paying for.

I like that alignment much better.

This is not fluffy “outcome-based consulting”

There is a version of outcome-based consulting where the provider starts claiming responsibility for enormous business outcomes they do not actually control. Increase revenue by 20 percent. Reduce headcount by 30 percent. Double productivity.

That gets silly pretty quickly because too many variables sit outside the provider's control.

I think there is a much cleaner boundary. Forceworks can be accountable for delivering an agent that performs an agreed process to an agreed standard. The customer remains accountable for what they do with the capacity, speed, or opportunity that capability creates.

Maybe they reduce costs. Maybe they grow without hiring. Maybe they allow people to spend more time on higher-value work. Maybe a process that previously took two days now takes two minutes. Those are legitimate business outcomes, but they belong to the customer.

Our job is to make the capability real.

The math should work without gymnastics

Imagine a process is consuming roughly $12,000 a month of organizational capacity today. Maybe that is direct labor cost, maybe it is opportunity cost, or maybe it is some combination of both.

Now imagine the agent costs $1,000 a month in Azure and model consumption, and our subscription is $5,000. The customer still has roughly $6,000 a month of value left over, before considering any additional benefit from speed, consistency or increased capacity.

That starts to look interesting.

Now flip the numbers around. If the process is only worth $2,000 a month and the agent costs $1,500 a month to operate before we even consider our subscription, then we probably shouldn't build it.

There is no prize for automating something badly.

This is another reason I like the Agent Factory model. If the economics stink, they stink for us too. We don't want an agent burning $10,000 a month in model consumption to replace $3,000 worth of work, and the customer obviously doesn't want that either.

Microsoft might be fine with it, but the rest of us should probably have a better plan.

It also runs in your Microsoft environment

Another thing we did not want to do was create some giant Forceworks AI cloud where customers send us their business processes and data.

That feels like the wrong direction.

The agents we build run in the customer's Microsoft Azure environment. The customer controls the Azure resources and pays Microsoft and model consumption directly, while their existing identity, security, governance, and infrastructure investments remain relevant.

That does not mean every system the agent touches has to be Microsoft. Real businesses obviously do not operate that way. If an agent needs to interact with something outside the Microsoft boundary, it can. But the center of gravity remains the customer's environment, not ours.

We are not trying to build another data silo, and we are not marking up token consumption. In fact, because we do not make more money when the agent consumes more AI, we have every incentive to keep reducing that cost over time.

I suspect that will become a much bigger issue than people think as agents move from demos into real operating workloads.

I think AI adoption will happen process by process

There is still a tendency to talk about AI transformation as though a company is going to wake up one Monday morning and become AI-powered.

I doubt that is how most of this happens.

I think it will happen much more quietly. A company finds one process where an agent makes sense, builds it, proves it, puts it into production, and then looks for the next one. That process repeats, and a year later the organization may operate quite differently even though there was never some giant moment where “AI transformation” officially occurred.

It accumulated.

That is also why we called this Agent Factory. The agents themselves are not standardized and may have almost nothing in common with one another. What is repeatable is the method: find the process, underwrite the economics, define what success means, build the agent, prove it works, and then operate it.

Then do it again.

So, bring us something real

We have opened applications for free Agent Factory Workshops, but these are not generic AI brainstorming sessions where twenty people throw Post-it notes on a wall, and somebody takes pictures of them.

Bring us one real business process that is consuming meaningful time, money, or capacity.

We will work through how it operates today, what an agent would actually have to do, which systems it would need, what the likely operating costs look like, and whether there is enough economic value to justify building it.

If we think there is a real business there, we may fund the development.

And if there is not, figuring that out before somebody starts writing checks seems like a pretty good outcome too.

To me, that is a much more rational way to build AI agents.