The Silicon Valley playbook has worked the same way for decades. Raise venture capital. Recruit elite engineers from MIT, Stanford, Carnegie Mellon. Build sophisticated software. Then fly into Cincinnati or Milwaukee or Kansas City to explain to manufacturers and logistics companies why they need your product.

Here’s what nobody says out loud: the people who actually understand those manufacturers’ problems already left Cincinnati for Mountain View.

And here’s what’s changing: they don’t need to anymore.

We’re entering an era where context is no longer overshadowed by capital. The hard-won operational knowledge, the decade of watching orders flow through a system, the battle scars from five ERP implementations, the trust earned from solving real problems, this matters more than your tech stack.

Agentic AI and coding LLMs are picking apart the moat that separated people who understand problems from people who can build software. The question isn’t whether this shift is happening. The question is whether the people with context will realize it before the next wave of well-funded startups figures out how to truly take advantage of it.

Visit Moltin

The formula is clean.

Raise a seed round. Hire engineers at $200K base plus equity. Build for six months. Launch. Iterate. Raise Series A. Scale the team.

Eventually you’ll need to understand your customers, but that comes later. First: product. The assumption is that smart people can figure out any domain if they’re smart enough.

This works until it doesn’t. But the extraction continues either way.

Product or Customer-First?

When you raise $10 million before you have customers, you build what investors find exciting.

That's not cynicism, it's incentives.

You build elegant APIs. Beautiful dashboards. Impressive demonstrations. You optimize for the next funding round, not for the warehouse manager who'll actually use the software at 5 AM when the overnight shift is short-staffed.

Imagine that you are part of a team of engineers that builds inventory management software. It's technically sophisticated, genuinely impressive architecture. They demo it to a mid-sized distributor in Ohio. The distributor's ops manager asks: "How does this handle partial pallet picks with mixed lot numbers when the forklift driver doesn't have both hands free?"

Silence. That scenario wasn't in the user stories.

The ops manager has been managing that warehouse for nineteen years. She knows every workaround in their current system. She knows why they track things the way they do, even if it seems weird to outsiders. She knows what breaks when you're short-staffed, when a SKU gets discontinued, when a supplier changes packaging mid-season.

The engineers will learn this eventually. They'll hire domain experts, usually expensive consultants or a VP who worked at a competitor. They'll do customer research, build personas, iterate.

It works well enough. But they're starting from zero on the understanding curve while charging premium prices from day one.

Context isn't tribal knowledge or institutional memory or any of those other soft phrases people use to avoid being specific. Context is concrete.

It's knowing that the production line always jams on Tuesdays because that's when they run the narrow-gauge material and the tensioner was installed slightly off-spec in 2019.

It's understanding that Purchase Order 4000-series numbers mean the order came through the EDI system and needs different handling than manually entered orders.

It's recognizing that when Customer X says they need something by Friday, they actually mean it needs to ship by Wednesday because their receiving dock is closed Thursdays.

This knowledge lives in people's heads, in email chains, in the muscle memory of experienced workers. Very little of it makes it into documentation. Almost none of it makes it into the requirements doc a consultant writes after three weeks of discovery interviews.

Hard-Won Lessons Beat Book Learning

You can’t teach someone in a conference room what it feels like when the system goes down during peak season. You can describe it. You can show them the incident reports. But they won’t know it the way the person who lived through it knows it.

That person understands which workarounds actually work under pressure. Which reports people will ignore no matter how prominently you display them. Which integrations are held together with duct tape and which ones are solid. Where the edge cases hide.

A developer fresh from a coding bootcamp can learn React in three months. Learning how a regional health system actually coordinates patient transfers across facilities? That takes years. And you need to be there, in the building, watching it happen.

Process Knowledge Is Underrated and Underpriced

Every company has an official process and an actual process. The gap between them is where context lives.

The official process says:

Sales receives order, enters it into the CRM, sends it to operations, operations schedules production, production updates the ERP, shipping coordinates delivery.

The actual process says:

Sales receives order over text message at 7 PM, calls their contact in operations because the online form times out half the time, operations checks with production lead verbally because the schedule in the system is always forty-eight hours behind reality, production updates a Google Sheet that three people check, shipping coordinates delivery by calling the customer directly because the delivery notes field in the ERP doesn’t sync with the carrier integration.

Software built around the official process fails.

Software built around the actual process works. But you only learn the actual process by being there.

Data Tells Stories If You Know How to Listen

Systems of record contain more truth than anyone wants to admit.

Not the sanitized data warehouse truth.

The messy operational database truth.

Why does that customer have seventeen different ship-to addresses? Because they’re a hospital network and each facility orders separately, but they all roll up to the same billing entity, and the address labeled “Main Campus” is actually a loading dock that’s only open Wednesdays.

Why are there three SKUs that seem identical? Because one is the old vendor code from before the acquisition, one is the new consolidated SKU, and one is what the legacy system calls it, and changing any of them would break reporting that Finance depends on.

Why does this order have a manual discount code applied? Because that customer’s buyer negotiated a deal in 2017 that’s not in any contract anyone can find, but everyone knows to honor it because the last person who didn’t got an angry call from the VP of Sales.

A data analyst from outside the company looks at this and sees data quality problems. Someone with context looks at it and sees the archaeological record of how the business actually works.

For thirty years, if you understood a business problem deeply but couldn't code, you had three options.

1. Hire developers.

2. Buy off-the-shelf software and force your process to fit it.

3. Or, do nothing.

That calculus has changed.

Coding LLMs Democratized Implementation

A senior software engineer at a major tech company makes between $300K and $500K in total compensation, according to 2024 levels.fyi data. That engineer brings deep technical knowledge, architectural thinking, and years of experience.

A domain expert with moderate technical literacy can now scaffold a working application using Claude, GPT-4, or Cursor in a fraction of the time it would've taken them to write specs for a developer.

The code isn't always elegant. It doesn't always follow best practices. But it often works.

I'm not saying LLMs write production-ready enterprise software on their own.

They don't.

But they compress the distance between "I know what needs to happen" and "I built something that does it."

That compression is nonlinear.

Tasks that required senior engineering talent, setting up authentication, building API integrations, creating database schemas, writing business logic, are now accessible to people who understand the problem but lack traditional coding expertise.

You still need to know what you're building and why. You still need to debug, test, iterate. But the barrier to entry dropped from "spend four years learning computer science" to "spend four weeks learning how to prompt and read code."

Technical Moats Are Eroding Fast

Every SaaS vendor’s pitch deck used to include a slide about their proprietary technology. Their advanced algorithms. Their sophisticated architecture. Their technical differentiation.

Most of that is becoming commoditized.

Building a React frontend? LLMs can scaffold it.

Setting up a PostgreSQL database with proper indexing? LLMs know the patterns.

Integrating with Salesforce’s API? LLMs have read the documentation.

Creating a scheduled job that processes data overnight? LLMs have written thousands of variations.

The technical complexity that used to justify $100M valuations is increasingly just configuration and integration work. Still necessary, still needs to be done right, but no longer a sustainable competitive advantage on its own.

What LLMs can’t commoditize is knowing what to build. Understanding that the nightly batch process needs to run at 2 AM, not midnight, because that’s when the upstream system finishes its own processing.

Recognizing that the “delivery date” field needs to be calculated differently for drop-ship orders versus warehouse stock. Knowing which reports people actually look at versus which ones get generated and ignored.

You can’t prompt your way to that knowledge. You earn it.

Agentic AI Accelerates the Shift

We’re moving past “LLMs help you write code faster” into “LLMs can manage entire workflows with minimal human intervention.” Agentic AI systems that can plan, execute, and iterate are still early. But they’re getting better quickly.

This matters because it further reduces the advantage of having a large engineering team.

A startup with fifty developers can build faster than a company with five developers. But if those five developers are equipped with AI agents that handle routine implementation, testing, and deployment?

The gap narrows.

The constraint shifts from “how fast can we write code” to “how well do we understand what needs to be built.”

And that brings us back to context.

None of this happens without Silicon Valley.

The irony of this entire argument is that the tools enabling domain experts to compete are themselves products of the capital-driven model we've been critiquing.

OpenAI, Anthropic, Google DeepMind, these companies raised billions to build the foundational models that make agentic AI possible.

They hired the world's best researchers. They built massive compute infrastructure. They iterated relentlessly on model architectures that most people still don't fully understand.

Without that investment, without that concentration of talent and resources, we wouldn't have Claude or Gemini 3 or any of the tools that compress the gap between understanding and execution.

The same goes for the infrastructure companies. Vercel makes deployment trivial. Stripe handles payments. AWS and Google Cloud provide enterprise-grade hosting that used to require entire ops teams. These are all products of the Valley ecosystem, built by well-funded teams solving hard technical problems at scale.

This isn’t a story about one model winning and another losing.

It’s about how the outputs of the capital-driven model, the AI platforms, the developer tools, the cloud infrastructure, are now available to people who historically couldn’t access them.

The Valley built the foundation. What’s changing is who gets to build on top of it.

The question isn't whether we need Silicon Valley's technical contributions.

We do.

The question is whether those contributions remain concentrated in companies that lack operational context, or whether they diffuse to people who've spent careers understanding real problems.

That diffusion is happening now. And it's happening because Valley companies chose to make their tools accessible rather than keeping them proprietary.

The Midwest doesn't have venture capital density. It doesn't have the same concentration of technical talent. It doesn't have the ecosystem of startups, acquirers, and experienced operators recycling through companies.

What it has is proximity to real complexity.

Manufacturing. Logistics. Agriculture. Healthcare delivery outside major metros.

These industries are operationally intricate in ways that make typical SaaS companies look straightforward.

They've been underserved by software for decades, not because there isn't money in them, but because the people who understand them and the people who can build software historically lived in different zip codes.

The People Who Stayed

Not everyone left for the coasts. Some people graduated with CS degrees and took jobs at local companies. Some taught themselves to code while working in operations or finance or logistics. Some came back after a few years in San Francisco or Seattle, burnt out on startup culture.

These people have something valuable that’s hard to acquire later: they never lost touch with the problems.

They’re embedded in industries that need better software.

They have relationships with potential customers because they’ve worked alongside them for years. They understand the constraints, the workflows, the politics, the unspoken rules. They know which problems are worth solving because they’ve felt the pain personally.

What they historically lacked was the ability to build software at the level of sophistication that venture-backed startups could produce.

That gap is closing.

Context as Competitive Advantage

A Silicon Valley startup selling to manufacturers will hire a few people with industry experience. Maybe a VP of Sales who worked at a competitor. Maybe a solutions engineer who came from the industry. They’ll do discovery calls, build personas, run design sprints.

It helps.

It’s better than nothing.

But it’s not the same as ten years on the plant floor.

The person with ten years on the plant floor knows things that don’t come up in discovery calls. They know the seasonal patterns, the personality dynamics, the unwritten rules. They know which features will actually get used and which ones will look good in demos but gather dust in production.

They can build something that fits how people actually work instead of how they’re supposed to work.

That’s worth more than elegant code.

There’s a critical choice companies face when adopting AI.

Do you build internal capability or outsource to vendors?

Most take the path of least resistance.

Hire a consultant. Buy a platform. Let someone else handle the complexity. It’s faster. It’s cleaner. It’s also how you end up dependent on vendors who don’t understand your operations.

The problem with outsourcing AI implementation is the same problem we’ve been discussing throughout this article. The vendor builds what they think you need based on discovery calls and requirements docs. They deploy their generic solution. They train your team on their interface. Then they leave.

You’re locked into their workflow, their update cycle, their pricing model. When your business changes, you’re waiting on their product roadmap.

Building internal capability is harder. It requires investment in your own team. It means accepting that your first attempts won’t be perfect. It means resisting the impulse to hand the problem to experts who promise to solve everything.

But it’s also how you maintain control over your competitive advantage.

There’s a gap opening up. Silicon Valley vendors are selling features without understanding workflow reality. People with context can now build solutions that actually fit.

That’s an arbitrage opportunity.

Selling Features vs. Solving Problems

Enterprise software sales runs on feature checklists. Does it have SSO? Does it integrate with Salesforce? Does it support role-based permissions? Does it have an API?

Procurement departments use these lists to evaluate vendors. Everyone knows it’s somewhat absurd. Having a feature and having a feature that works well for your specific use case aren’t the same thing. But it’s an easy way to narrow the field.

Meanwhile, the actual users, the people who’ll spend eight hours a day in the software, care about different things. Does it make their job easier? Does it fit their workflow? Does it avoid forcing them to do unnecessary steps? Does it surface the information they need when they need it?

Vendors optimized for the procurement process often miss on the actual user experience. They build broad, generic tools that technically check all the boxes but feel clunky in practice.

Someone with context builds narrow, specific tools that skip the procurement checklist but nail the user experience. In a world where you can build software cheaply with AI assistance, that’s a viable strategy.

Being the Customer You Serve

Product-market fit is easier when you are the market. You don’t need to do user research to understand the pain points. You feel them. You don’t need to validate demand.

You know it exists because you’d pay for a solution yourself.

This removes whole categories of risk that plague traditional startups. You’re not guessing whether anyone will want this. You’re not iterating based on survey responses from people you met at a conference. You’re building for yourself and people like you.

It also means you can start small and bootstrap. You don’t need venture capital to validate the idea. You need enough revenue from your first few customers to keep developing.

That’s achievable when those customers are people you already know and the development costs are low because you’re using AI to accelerate execution.

Defending Against Disruption

Incumbent companies usually lose to startups because they’re slow to adapt and burdened by legacy systems. But what if the incumbent’s people build the new tools themselves?

That’s the ultimate defense against disruption. You maintain your context advantage, your customer relationships, your domain expertise. You just upgrade your technical capability.

A manufacturer that builds its own production planning tools, tailored exactly to its processes, doesn’t need to fear the generic MES vendor.

A regional health system that builds its own patient coordination software, designed around its actual workflows, doesn’t need to fear the EHR add-on modules.

The technology stops being the bottleneck.

Context becomes the moat.

AI hasn’t eliminated the need for capital, technical skill, or go-to-market strategy. It’s shifted the equation, not erased it.

AI Tools Still Require Sophistication

Prompting an LLM to write code is easy. Getting it to write good code is hard. Knowing when the code it wrote is wrong, knowing how to fix it, knowing how to architect a system that won’t collapse under real-world load, these things still require expertise.

You can learn this expertise faster than you could’ve learned traditional software development. The on-ramp is shorter.

But there’s still an on-ramp.

Someone with zero technical background can’t just start shipping production software after reading a blog post about prompt engineering.

They can start building useful tools for themselves and their team. That’s not nothing. But scaling from there to a sustainable enterprise-grade solution requires learning.

Capital Still Matters for Scale

Building your first version cheaply doesn’t mean you can scale cheaply. At some point you need infrastructure, security, compliance, customer support, sales, marketing.

That costs money.

Bootstrapping works for some businesses. Venture capital works for others. The shift isn’t that capital becomes irrelevant.

It’s that you can get further before you need it.

You can prove more, de-risk more, build more leverage.

That changes the power dynamic in fundraising conversations. It doesn’t eliminate the need to have them.

Valley Startups Can Hire Domain Experts

Nothing stops a well-funded startup from hiring people with deep industry experience.

They do it all the time. They pay well for it.

The difference is timing and cost. They usually hire domain experts after they’ve built the first version, when they realize they need help understanding customers.

By then they’ve made architectural decisions that are expensive to change. They’ve built features that seemed important but aren’t. They’ve skipped things that seemed minor but matter.

Hiring expertise later is possible. It’s just less efficient than starting with it.

Network Effects and Ecosystem Advantages

Silicon Valley has network effects that won’t disappear. Experienced operators who’ve built companies before. Investors who’ve seen patterns across hundreds of deals. Talent density that makes hiring easier. Acquirers who look there first.

These advantages compound. They’re real. They’re valuable. They’re also not insurmountable, especially for businesses that don’t need to scale to billions in revenue to be successful.

A company doing $20M in revenue with strong margins and happy customers doesn’t need to be in San Francisco. It needs to be where its customers are and where its domain experts want to live.

We’re not witnessing the death of venture capital or the end of Silicon Valley. We’re watching context get repriced.

For decades, technical execution capability was scarce and valuable. Domain knowledge was common and cheap. Software companies could hire industry experts for a fraction of what they paid engineers. The engineers were the constraint.

That ratio is shifting. Technical execution is becoming less scarce as AI tools democratize development.

Domain knowledge, real, deep, operational expertise, remains as hard to acquire as ever. Maybe harder, given how many experienced practitioners left their industries for tech jobs.

The people who stayed close to real problems, who kept learning how things actually work, who maintained relationships with potential customers, those people now have leverage they didn’t have before. They can build solutions that well-funded outsiders struggle to replicate.

This doesn’t mean every domain expert should quit their job and start a software company.

Most won’t. Most shouldn’t.

But some will. And when they do, they’ll have advantages that capital alone can’t overcome.

The next decade of B2B software might look less like “Stanford CS grads disrupt industry X” and more like “industry X builds its own tools.”

That would be a welcome change.

The best solutions to complex problems usually come from people who’ve lived with those problems long enough to understand them completely. We’re finally reaching a point where those people can build the solutions themselves.

They just needed the tools to catch up with their knowledge.

In January 2025, a Chinese AI lab called DeepSeek released a reasoning model that reportedly cost $5.6 million to train. For context, OpenAI spent somewhere north of $100 million training GPT-4. The internet declared a paradigm shift. Nvidia lost nearly $600 billion in market cap in a single day. And Microsoft CEO Satya Nadella fired off a LinkedIn post quoting a 19th-century British economist.

That economist was William Stanley Jevons. His observation, now called the Jevons Paradox, is simple and a little unsettling:

When you make a resource more efficient to use, people don’t use less of it. They use more. Much more.

Jevons watched this happen with coal in 1865. After James Watt’s improved steam engine arrived, factories didn’t burn the same amount of coal to do the same work. They burned more coal to do vastly more work. Efficiency didn’t conserve the resource. It unlocked demand that didn’t exist before.

Now replace coal with compute. And steam engines with agentic AI.

Here’s what worries me, and what should probably worry you too. When every enterprise deploys the same efficient AI models to automate the same kinds of work, the Jevons Paradox doesn’t just predict more AI usage. It predicts an explosion in AI activity, compute demand, energy consumption, and competitive pressure, all at once.

Efficiency is no longer a cost-saving measure. It’s a trigger.

Visit Moltin

From Interfaces to Labor

For most of its commercial life, AI has been an interface. You ask it something, it answers. The interaction ends. The cost per query was low enough to be a rounding error for most companies, and the value was real but bounded. Customer support bots, code suggestions, search summaries.

Agentic AI is something different. An agent doesn’t just answer a question. It takes a goal, breaks it into steps, uses tools, makes decisions, and executes. It does labor. And when the cost of that labor drops, the economics of automation change completely.

Think about what was previously too expensive to automate.

• Researching 500 target accounts for a sales team.

• Monitoring competitor pricing across 200 SKUs every hour.

• Running personalized outreach sequences that actually adapt to responses.

• Drafting compliance documentation for every product variant.

These tasks weren’t automated because a human doing them costs real money, but not so much that anyone was going to build a custom software system for it. They lived in the gray zone between too expensive to ignore and too complex to automate cheaply.

Efficient, cheap AI agents dissolve that gray zone. When the cost of an agent running a complex, multi-step workflow drops by an order of magnitude, the entire frontier of “economically viable automation” shifts.

Tasks that used to require a full-time hire now cost a few dollars a day. And companies don’t stop at replacing what they were already doing. They start doing things they never did before.

That’s Jevons at work. Lower cost doesn’t shrink consumption. It expands it into territory that was previously off-limits. The moment AI stops being an interface and starts being labor, the demand curve stops looking like a gentle slope and starts looking like a hockey stick.

DeepSeek’s R1 didn’t just prove that efficient models were possible. It proved they were coming. And every enterprise watching that news cycle started doing the same mental math.

The Red Queen Problem

Here’s the competitive trap that nobody is talking about loudly enough. If every company has access to the same high-efficiency AI models, then no single company gains a lasting edge from the tool itself. The tool is table stakes. What you do with it is the game.

This creates what evolutionary biologists call a Red Queen dynamic. In Lewis Carroll’s Through the Looking-Glass, the Red Queen tells Alice that in her country, “it takes all the running you can do, to keep in the same place.”

When everyone is running faster, standing still means falling behind. Competitive pressure doesn’t disappear when a technology becomes commoditized. It intensifies, because the floor just rose.

So what do companies actually do when everyone has the same tools? They race on three dimensions.

Volume

The first response is to deploy more agents faster. If your competitor’s sales team is running 10 AI-assisted outreach sequences, you run 100.

If they’re monitoring their top 50 accounts, you monitor 5,000.

Volume is the most obvious lever, and it’s the one that shows up first. It’s also the one that directly drives Jevons-style demand expansion. You’re not replacing one human’s workload.

You’re creating a workload no human could’ve carried.

Complexity

Volume alone doesn’t win for long. So the second move is to build more complex, proprietary systems on top of the same efficient models. A generic agent is easy to copy. An agent that’s deeply integrated with your proprietary data, your business rules, your customer history, and your operational workflows is not.

Complexity is how you make cheap infrastructure into a real moat.

Complexity, however, is becoming less expensive to build but remains expensive to run. More elaborate agent systems require more compute, more monitoring, more iteration. The efficiency gains at the model layer get eaten up by the complexity added at the system layer.

This is the paradox in microcosm. Cheaper inference leads to more ambitious deployments, which leads to higher total spending.

Constant Iteration

The third lever is speed of experimentation. When the cost to run an agent workflow drops, so does the cost to fail. Companies start running thousands of automated experiments that would have been cost-prohibitive six months ago.

A/B tests on outreach copy. Variant testing on pricing strategies. Parallel evaluation of different agent architectures. Low failure cost means high experiment volume, which means high compute demand.

The competitive logic is self-reinforcing. Efficiency enables scale. Scale creates pressure. Pressure demands more scale. Nobody calls a timeout.

In a Red Queen race, the winner isn’t the one who runs the farthest. It’s the one who keeps running longest without falling over.

A Bill Nobody Budgeted For

Nadella’s LinkedIn post wasn’t just economic theory. It was a signal. After DeepSeek’s release, the instinct was to say that cheaper AI meant less infrastructure investment. Nadella said the opposite. More efficient models will drive more usage, which will drive more infrastructure demand. The GPU boom doesn’t slow down. It accelerates.

The numbers are starting to bear that out.

The Math Nobody Wants to Do

According to the International Energy Agency’s 2025 report on Energy and AI, global electricity consumption from data centers is projected to roughly double, reaching around 945 TWh by 2030.

In the United States specifically, the IEA projects data center power consumption will increase by approximately 240 TWh compared to 2024 levels, a rise of about 130%.

A 2024 study published in Nature Sustainability, conducted by researchers from Oxford, Cornell, KTH Royal Institute of Technology, and others, projected that AI servers in the U.S. alone could consume between 220 and 532 terawatt-hours annually by 2030, potentially reaching up to 10% of the nation’s current electricity usage.

On the higher end of projections, the National Center for Energy Analytics estimates that combined data center and broader digital infrastructure demands could approach 15 to 20% of overall U.S. electricity demand in the early 2030s.

Here’s what makes this particularly hard to solve. Each individual AI inference operation is getting more efficient. But the total number of inferences is growing so fast that per-unit efficiency gains can’t keep pace. When you make each “thought” cheaper, people schedule a trillion more of them.

Demand Follows Efficiency Down

The infrastructure industry is already feeling this. Vertiv, one of the major data center equipment suppliers, reported a 29% revenue increase and 60% order growth in Q3 2025, with a backlog of $9.5 billion, according to Data Center Dynamics. That’s not the profile of a market slowing down after an efficiency breakthrough. That’s a market that believes the workload is coming.

Some infrastructure analysts have observed a rough pattern. For every significant reduction in inference costs, deployment requests tend to increase by multiples, not percentages.

The exact multiplier varies by market and model generation, but the direction is consistent. Cheaper compute doesn’t reduce compute demand. It changes what compute demand is applied to.

Meta raised its 2025 AI infrastructure spending to $60-65 billion after DeepSeek’s release, not despite it. That’s the Jevons Paradox in a budget line item.

The Debate That Matters

The energy question is important. But the question most people actually care about is the job question. And on this one, Jevons gives us less certainty.

The optimistic case draws from the pattern. When printing became cheap, more writers were employed, not fewer. When photography became affordable, more photographers existed, not fewer. When spreadsheets replaced manual calculation, more financial analysts were hired.

In each case, cheaper access to a tool expanded the total market for the skill, rather than eliminating it. Applied to AI: cheaper agents should expand demand for the humans who design, manage, and improve those agents.

Digital marketing is a reasonable example. AI has made content creation, ad targeting, and campaign analytics dramatically cheaper. The field has grown, not contracted.

More companies now do digital marketing than before, more ambitiously than before, because the cost to enter and scale dropped. The humans got more productive, not more unemployed.

But there’s a counterargument that’s harder to dismiss than the optimists like to admit. The historical cases involved tools that augmented human skills. A camera still required a photographer. A spreadsheet still required an analyst. The tool extended what the human could do.

Agentic AI is different in a specific way. It can substitute for human cognition, not just extend it. An agent can reason, decide, communicate, and iterate without a human in the loop.

If AI is a substitute for thinking, not just a tool for thinkers, then the Jevons rebound in employment may not apply. You might get more tasks done, without more humans doing them.

The honest answer is that we don’t know yet. The historical analogies are instructive but imperfect. The people who are most confident in either direction are probably the most wrong.

What we can say is that the transition period, the years between “agents are novel” and “agents are infrastructure,” will be genuinely disruptive regardless of where it lands. The people who will fare best are the ones who understand what the agents can’t do yet, and who build that as their competitive advantage.

What This Means for Enterprise Strategy

If you take Jevons seriously, a few things follow.

First, the efficiency gains from better models are real and genuinely useful. But they don’t reduce your total AI spend. They redirect it. You’ll spend the savings on volume, on complexity, on experiments you couldn’t run before.

Budget accordingly. The CFO who thinks AI efficiency means a smaller AI line item is going to be surprised.

Second, the competitive advantage isn’t the model. It’s what you build on top of the model. The race to differentiate will happen at the data layer, the integration layer, and the workflow design layer.

Proprietary data, tight operational integration, and genuine domain expertise are your moat. The underlying model is just coal.

Third, governance matters more than it did. When AI moves from answering questions to executing decisions at scale, the failure modes get bigger. A bad answer to a question is a minor annoyance. A bad agent running thousands of customer interactions or making thousands of pricing decisions before anyone notices is a different category of problem. Speed of iteration has to be matched by speed of oversight.

Fourth, energy and infrastructure are real cost inputs now. The bill for all this AI activity is going to show up somewhere. For companies running large agentic deployments, compute costs are becoming a significant operational expense.

The teams that treat this as an engineering and procurement problem, rather than just a technology problem, will have a real cost advantage.

Jevons was writing about coal in 1865, but his insight holds for any resource where efficiency unlocks demand that was previously constrained by cost. He wasn’t being pessimistic. He was just being accurate.

The question isn’t whether AI adoption will slow down as models become more efficient. It won’t.

The question is whether you’re building for the scale that comes next, or assuming that efficiency means things get simpler. They don’t.

They get faster.

Sources

• International Energy Agency (IEA). “Energy and AI.” April 2025. https://www.iea.org/reports/energy-and-ai

• Nature Sustainability / Environmental Change Institute, University of Oxford. “AI Could Consume 10% of U.S. Electricity by 2030.” 2024. https://www.eci.ox.ac.uk/news/ai-could-consume-10-us-electricity-2030-researchers-outline-path-sustainable-growth

• National Center for Energy Analytics. “The Rise of AI: A Reality Check on Energy and Economic Impacts.” November 2025. https://energyanalytics.org/the-rise-of-ai-a-reality-check-on-energy-and-economic-impacts/

• Nadella, Satya. LinkedIn / X post. January 27, 2025.

• Fortune. “What is Jevons paradox? The reason Satya Nadella says DeepSeek’s new AI is good news for tech.” January 27, 2025. https://fortune.com/2025/01/27/microsoft-ceo-satya-nadella-deepseek-optimism-jevons-paradox/

• NPR Planet Money. “Why the AI World is Suddenly Obsessed with Jevons Paradox.” February 4, 2025. https://www.npr.org/sections/planet-money/2025/02/04/g-s1-46018/ai-deepseek-economics-jevons-paradox

• S&P Global. “Global Data Center Power Demand to Double by 2030 on AI Surge: IEA.” April 10, 2025.

  https://www.spglobal.com/energy/en/news-research/latest-news/electric-power/041025-global-data-center-power-demand-to-double-by-2030-on-ai-surge-iea

• Data Center Dynamics. “Vertiv Revenue Jumps 29% on Booming Data Center Demand.” October 2025.

  https://www.datacenterdynamics.com/en/news/vertiv-revenue-jumps-29-percent-on-booming-data-center-demand/

You're building an agentic AI system. One of the first questions you'll face is deceptively simple: should you use one agent or many?

Here at Moltin, we've spent the last year implementing both approaches across hundreds of workflows. The answer isn't what most vendors will tell you. It's not about which architecture is "better." It's about matching the right pattern to your specific problem.

Visit Moltin

What We’re Really Talking About

A single-agent system uses one AI model to handle an entire workflow from start to finish. Think of it as hiring one very capable person to manage a project. They understand the full context, make all the decisions, and own the complete outcome.

Multi-agent systems split work across specialized agents. Each one handles a distinct piece of the puzzle. One agent might research information while another validates it and a third formats the output. They coordinate through structured handoffs or shared memory.

The difference isn't just architectural. It changes how you debug, how you scale, and how much you'll spend on tokens.

The Single-Agent Advantage

One agent means one context window. One set of instructions. One failure mode to debug. When something breaks at 2 AM, you’re not trying to figure out which agent in a chain of six dropped the ball.

I’ve watched teams spend weeks debugging multi-agent coordination issues that turned out to be simple prompt problems. With a single agent, you see the issue immediately. The model either understands the task or it doesn’t.

Deployment is faster too. You write one system prompt, test one set of behaviors, and push to production. No orchestration layer. No message queues. No distributed tracing to make sense of what happened.

Single agents maintain perfect context throughout a task. They remember what they learned in step one when they reach step five. There’s no lossy handoff between specialists who each see only part of the picture.

This matters more than you’d think. I’ve seen multi-agent systems hallucinate because Agent C never saw the constraint that Agent A discovered. The information got lost in translation between handoffs. A single agent can’t forget what it already knows.

The model can also adapt its strategy mid-execution. If the initial approach isn’t working, it pivots without needing to coordinate with three other agents. The flexibility is real.

Cost Efficiency for Straightforward Tasks

Here’s something vendors don’t advertise: multi-agent systems are expensive. Each agent generates tokens. Each handoff requires additional context-setting. You’re paying for coordination overhead on top of the actual work.

For tasks that don’t require true specialization, that overhead is waste. I’ve measured cases where multi-agent implementations cost 3-4x more in API calls than equivalent single-agent solutions. Same output, same quality, quadruple the bill.

If your workflow is linear and doesn’t branch much, one agent will almost always be cheaper. Save your budget for problems that actually need multiple perspectives.

When Single Agents Hit the Wall

Modern models have large context windows. Claude can handle ~200,000 tokens. Gemini can handle ~1,000,000 tokens. But just because you can stuff an entire workflow into one context doesn’t mean you should.

I’ve seen single agents lose the thread around the 50,000-token mark. They start forgetting instructions from the beginning. They repeat themselves. The quality degrades in ways that are hard to predict.

Complex workflows with lots of branching logic hit this wall fast. If your task has ten decision points and each one requires evaluating thousands of tokens of information, you’re asking one agent to juggle too much. The drops become inevitable.

Some tasks genuinely benefit from expertise. You wouldn’t ask a surgeon to also handle anesthesia and nursing. The same principle applies to agents.

A single agent trying to do everything becomes a generalist. It’s decent at research, okay at analysis, passable at formatting. But if you need expert-level SQL generation followed by expert-level data visualization, a generalist often falls short.

Single agents handling complex data pipelines make subtle mistakes that specialized agents catch. The SQL agent understands database-specific quirks. The visualization agent knows what makes charts readable. One agent trying to do both gets neither quite right.

When a single agent fails on step eight of a twelve-step process, you’ve got a mess. The error could be anywhere in the logic. The context is enormous. Good luck isolating the root cause.

You end up re-running the entire workflow repeatedly, tweaking prompts, hoping you’ve fixed it. Each test cycle burns time and money. There’s no easy way to unit-test just the part that’s broken.

Multi-agent systems let you isolate failures to specific agents. When the validation agent throws an error, you know exactly where to look. You can test that agent independently without running the full workflow.

The Multi-Agent Case

Breaking work into specialized agents forces clarity. Each agent has one job, and you can tune it specifically for that job. The research agent doesn’t need to know anything about formatting. The formatter doesn’t need research capabilities.

This separation makes prompts simpler. Instead of one massive system prompt trying to cover every scenario, each agent gets focused instructions. Less ambiguity means fewer edge-case failures.

It also makes the system easier to reason about. When you read the workflow diagram, you immediately understand what’s happening. Research feeds into validation, which feeds into formatting. The data flow is explicit.

Some workflows have natural parallelism. You need to check three different data sources simultaneously, or generate multiple variations of content to compare.

Multi-agent systems can run these operations concurrently. One agent hits the CRM while another queries the analytics platform and a third searches internal documentation. You get results in the time it takes the slowest agent to finish, not the sum of all three.

I’ve cut workflow execution time by 60-70% using parallel agents for tasks that don’t have strict dependencies. The speedup is real and it compounds as workflows grow.

Not every step needs your most powerful (and expensive) model. The agent that validates email addresses can run on a cheaper, faster model than the agent writing customer communications.

Multi-agent architectures let you optimize the cost-performance ratio for each piece. Use Opus for creative writing. Use Haiku for structured extraction. Use Sonnet for reasoning-heavy tasks.

This flexibility matters at scale. I’ve seen companies cut inference costs by 40% just by right-sizing models to tasks. The overall system gets faster too because simple agents finish quickly and don’t block the workflow.

When you need to improve the validation logic, you modify one agent. You test it in isolation. You deploy just that change. The rest of the system keeps running with zero risk.

This is dramatically different from modifying a monolithic agent. With single agents, every change touches the entire system. You’re never quite sure if you fixed the validation without breaking the research or formatting.

Multi-agent systems also support A/B testing. Run the old validation agent for 50% of requests and the new one for the other 50%. Compare results. Roll back instantly if the new agent underperforms.

The Hidden Costs of Multi-Agent Systems

Coordination Overhead

Agents don’t communicate telepathically. You need infrastructure to pass messages, share context, and synchronize state. This coordination layer is code you have to write, test, and maintain.

Every handoff between agents is a potential failure point. What happens if Agent B crashes after Agent A finishes? Do you retry? Do you start over? How do you ensure exactly-once processing?

I’ve seen teams spend more time building orchestration logic than actually implementing agent behaviors. The complexity creeps up on you. Suddenly you’re maintaining what’s essentially a distributed system with all the headaches that entails.

Debugging Distributed Failures

When a multi-agent workflow fails, tracing the issue requires following the execution path across agents. You need distributed logging, correlation IDs, and good observability. Otherwise you’re flying blind.

Even with great tooling, debugging is harder. The problem might be in Agent C, but it was caused by bad output from Agent A that Agent B didn’t catch. You’re doing root cause analysis across a chain of dependencies.

I’ve spent hours debugging issues that turned out to be prompt drift. Agent A changed its output format slightly, and Agent C couldn’t parse it anymore. Agent B in the middle passed it through without noticing. These cascading failures are subtle and time-consuming.

Prompt Drift and Version Management

You’ve got multiple agents, each with its own prompt. You update Agent B’s prompt to fix a bug. Now Agent B’s outputs have changed slightly, and Agent D downstream is confused.

Managing prompt versions across a system of agents is genuinely difficult. You need testing matrices that verify agent pairs still work together after updates. You need rollback plans. You need change logs.

Single agents don’t have this problem. There’s one prompt. You version it. Done.

Making the Choice

Start with task complexity. Map out your workflow on paper. How many distinct steps are there? How much context does each step need from previous steps?

If the workflow is linear and each step builds directly on the last with heavy context requirements, lean toward a single agent. The task probably doesn’t need decomposition.

If you see clear breakpoints where one phase completes and hands off to a fundamentally different phase, that’s a signal for multi-agent. Research, then analysis, then formatting is a classic pattern that benefits from separation.

Consider your team’s capabilities. Multi-agent systems require stronger engineering. You need people who understand distributed systems, message passing, and state management. If your team is small or light on infrastructure experience, single-agent is safer.

You can always start simple and refactor later. I’ve seen too many teams over engineer from day one, building elaborate multi-agent frameworks before they’ve shipped a single workflow. Start with one agent. Prove the value. Then optimize.

Think about the maintenance burden. Who’s maintaining this system in six months? Multi-agent architectures create more surface area. More code. More potential breakage. More operational complexity.

If you’re building a one-off workflow, keep it simple. If you’re building a platform that’ll run thousands of workflows, the investment in proper multi-agent infrastructure might pay off. Scale matters.

Test both when possible. The best answer comes from empirical data. Build a prototype with a single agent. Build another with multiple agents. Run them both on real tasks and measure what actually matters: accuracy, latency, cost, and maintenance burden.

I’ve been surprised more than once. Tasks I thought needed multi-agent worked fine with one. Tasks that seemed simple benefited from specialization. Your intuition will be wrong sometimes.

Hybrid Approaches

You don’t have to choose just one pattern. Some workflows use a single agent for most of the work and spawn specialized agents for specific subtasks.

For example, your main agent handles the workflow logic but calls out to a specialized SQL agent when it needs to generate queries. The SQL agent is isolated, testable, and optimized. But you’re not managing a full multi-agent orchestration system.

This middle ground often makes sense. You get specialization where it matters without the overhead of coordinating everything through message passing. The main agent stays in control and maintains context.

I’ve used this pattern for workflows that are mostly straightforward but have one or two steps that need deep expertise. It’s the best of both worlds when it fits.

What the Research Shows

Academic papers love multi-agent systems. They’re fascinating to study and produce impressive demos. But research metrics don’t always transfer to production.

Many papers test on toy problems or benchmarks that favor coordination. They measure agent collaboration in controlled environments. Real workflows are messier. They have edge cases, noisy inputs, and strict latency requirements.

The research also rarely accounts for operational costs. A system that scores 2% better on accuracy but costs 4x more and takes twice as long to debug isn’t obviously better. Context matters.

That said, the research does validate some patterns. Specialized agents consistently outperform generalists on complex reasoning tasks. Parallel execution really does speed things up. The findings are directionally correct even if the magnitude is overstated.

The Evolution Path

Most successful agentic systems start simple and grow in complexity. You begin with a single agent handling a narrow workflow. You ship it. You learn what breaks.

Then you identify the bottleneck. Maybe it’s the research phase that’s slow. Maybe the formatting is error-prone. You extract that piece into a specialized agent. You test it. You measure the impact.

Over time, you end up with a hybrid system that’s grown organically based on real needs. This beats starting with a grand multi-agent architecture that turns out to be overbuilt for the actual problem.

I’ve never seen a team regret starting simple. I’ve seen plenty regret starting complex.

Lessons from the Field

After shipping dozens of agentic workflows, here’s what I’ve learned matters most:

Single agents shine when context coherence is critical and the task is straightforward. Use them for workflows where losing the thread would be catastrophic. Use them when you need fast iteration and simple debugging.

Multi-agent systems win when specialization improves quality or parallelism cuts latency. Use them when different steps genuinely need different expertise. Use them when you can afford the coordination overhead.

The decision isn’t permanent. You can refactor. But you’ll ship faster and learn more by starting with the simplest thing that could work.

Most teams overcomplicate. They read about sophisticated multi-agent frameworks and assume they need that level of sophistication. They don’t. Not yet anyway.

Build one agent that solves a real problem. Ship it to users. Collect feedback. Then decide if you need more agents. Let the actual requirements drive the architecture, not the other way around.

That’s how you build agentic systems that actually work.

Visit Moltin

I spent three years building Moltin before writing this article. The experience has taught me something uncomfortable: technical elegance means nothing if the unit economics don't work.

Now I watch AI startups pitch with the same reverence for model performance I once had, completely blind to the margin trap they're building for themselves.

Angel investors have started walking away from AI deals. Yes, it has begun.

Not because the technology isn't impressive. It is. They're walking because the numbers don't add up.

When Bessemer Venture Partners analyzed fast-growing AI startups in 2025, they found "Supernovas" averaging 25% gross margins while traditional SaaS companies cruise at 75% or higher.

Some AI companies were running negative margins entirely.

This isn't FUD (Fear, Uncertainty, and Doubt) from people who don't understand AI. This is pattern recognition from investors who've seen infrastructure plays crater before. The concerns are valid. But they're also solvable if you face them early instead of pretending compute costs will magically fix themselves.

Visit Moltin

The Real Problem With AI Isn’t Hype, It’s Math

Traditional software has near-zero marginal costs. Build it once, sell it a million times. Every new user is almost pure profit. AI applications burn real money with every inference. Your 1,000th customer costs you actual dollars in compute, not just server pennies.

According to Stanford's 2025 AI Index Report, inference costs for GPT-3.5-level performance dropped 280-fold between November 2022 and October 2024.

That sounds encouraging until you read the fine print.

Those cost reductions apply to older, established models. Frontier models that startups actually need to compete? They're getting more expensive.

The agentic workflows everyone's building now consume 10-100x more tokens per task than simple chat completions did in December 2023, per an analysis from SaaStr.

Here's what that means in practice.

Early reports showed GitHub Copilot costing Microsoft roughly $80 per heavy user per month while charging $10. That's a $20 average loss per subscriber. In mid-2025, Cursor reportedly paid Anthropic $650 million annually while generating $500 million in revenue. Negative 30% gross margin.

Their response? Build proprietary models. Because at that margin profile, you don't have a choice.

The margin compression isn't subtle.

Bessemer's data shows AI "Shooting Stars" with more sustainable growth hitting 60% gross margins, which sounds better until you realize that's the floor for Series B conversations in traditional software.

Below 60%, investors start questioning whether you've built a software company or a services business with extra steps.

Why Investor Skepticism Is Actually Healthy

Every cycle has its moment of reckoning. For AI, we've hit the point where "we'll figure out margins later" doesn't fly anymore. This scrutiny isn't the market turning against AI. It's the market maturing.

Investors watched the zero-interest era fund companies that never had to prove unit economics.

That's over.

Interest rates rose, capital got expensive, and suddenly everyone cares about cash flow. PitchBook's 2025 data shows early-stage AI valuations compressing from a 74% premium over non-AI startups to just 30%, year-over-year.

Translation: investors are demanding proof.

The uncomfortable truth? Most AI startups haven't built businesses yet. They've built impressive demos that cost more to run than customers will pay. OpenAI itself lost $5 billion in 2024 on $3.7 billion in revenue, according to Market Clarity's analysis of profitable AI startups.

If the most successful AI company in the world operates at a loss, everyone else should probably have a plan.

But here's what the doom-and-gloom narratives miss. Anthropic expects gross margins to have improve from -94% in 2024 to 40% in 2025 and 77% by 2028.

OpenAI's compute margin jumped from 35% in January 2024 to 70% by October 2025, The Information reported. The trajectory is clear for companies that optimize deliberately instead of assuming scale will solve everything.

The question isn't whether AI companies can be profitable. It's which ones will be.

A Framework for Sustainable Economics

If you're building an AI startup right now, you need to make peace with a hard fact: your margins will be worse than traditional SaaS for at least the next few years. The game is showing investors a credible path from where you are to where software margins live. Here's how.

Know Your True Unit Economics From Day One

Most early-stage founders treat unit economics like a later-stage concern. That's backward. You need to know your cost-per-customer down to the token before you set pricing.

Build a model that tracks compute cost per customer, gross margin by user segment, and how those metrics change with volume. Include both your platform fees and the actual inference costs you're eating.

You don’t want to discover what happens when your power users cost 10x what light users do, but they're all paying the same price. You can't fix that problem if you don't measure it. Track usage patterns by cohort. Calculate what heavy usage actually costs you. Then price accordingly or accept that you're subsidizing growth at the expense of margins.

Your dashboard should show:

• Cost-per-inference

• Blended margin across customer segments

• CAC payback by cohort

If you can't pull those numbers in under five minutes, your financial infrastructure isn't ready for investor diligence.

Design Pricing That Reflects Reality

Flat subscription pricing made sense when software had zero marginal cost. With AI, it's financial malpractice. You can't charge every user $50/month when some consume $5 of compute and others burn $200. That's not a business model. That's a transfer payment from your light users to your heavy ones.

Bessemer's research shows that sustainable AI companies embrace hybrid models:

• Base subscription plus usage tiers.

• Compute credits that scale with consumption.

• Separate pricing for AI features versus traditional functionality.

Replit demonstrates this well. Their model layers a base subscription with usage credits for compute, AI agent calls, and hosting. Heavy users pay more. Light users get predictable costs. Margins improve as usage scales.

The key is aligning what customers pay with what they consume. Usage-based pricing feels uncomfortable if you've spent years in traditional SaaS.

Get over it.

The alternative is selling a dollar for eighty cents and calling it growth.

Build Margin-Enhancing Architecture

This is where your technical background matters. Inference costs aren't fixed. They're a function of architecture choices you make. Every decision about model selection, caching strategy, and prompt engineering directly impacts your margins.

Start with caching. If you're hitting your model provider for the same or similar queries repeatedly, you're burning money for no reason. Intelligent caching can reduce GPU costs by 5-10x according to infrastructure providers like Tensormesh.

Semantic similarity matching lets you serve responses from cache instead of recomputing. The first implementation is trivial. The margin improvement is immediate.

Model selection matters more than most founders realize. You don't need GPT-4 for every task. Build a router that uses cheaper models for simple queries and reserves frontier models for complex reasoning.

Progressive loading works: start with a fast, cheap model, escalate only when needed.

Cursor cut their compute costs dramatically by building proprietary models optimized for their specific use case instead of relying entirely on third-party APIs.

Prompt engineering seems like a minor optimization until you're processing millions of requests.

Shorter prompts mean fewer tokens. Fewer tokens mean lower costs.

Strip unnecessary context. Compress system messages. Format outputs efficiently. These micro-optimizations compound.

Infrastructure decisions have long-term margin implications. Negotiate annual contracts with your cloud provider instead of paying usage rates. Evaluate when self-hosted inference makes sense. Consider multi-provider strategies to optimize for cost versus latency versus availability.

These aren't problems you solve on day one, but you need a roadmap.

Diversify Beyond Pure AI Features

The companies with the best margins aren’t pure AI plays. They’re platforms where AI is one component in a larger value stack. Look at Replit. Their margins on hosting and infrastructure are significantly higher than margins on AI agent inference. The blended model works because not every dollar of revenue costs the same to deliver.

Canva proves this at scale. AI features enhance the product, but most of the value comes from design tools, templates, and collaboration features that don’t scale linearly with compute costs.

The AI makes the product better. The platform makes the margins defensible.

Build features that create switching costs without burning compute. For example:

• Data storage and organization.

• Collaboration and workflow tools.

• Integrations with existing systems.

• Marketplace dynamics where users create value for each other.

These layers don’t just improve retention. They improve margins.

Think about what you’re really selling. If it’s just a thin wrapper on someone else’s expensive model, you don’t have a business. You have a distribution play that ends the moment your supplier decides to compete with you.

Anthropic launched Claude Code. OpenAI has Codex. If your entire value proposition is “our UX on their model,” that advantage evaporates fast.

Verticalize and Differentiate

Horizontal AI tools face a race to the bottom on both pricing and margins. Everyone has access to the same foundation models. Everyone pays roughly the same inference costs.

Differentiation becomes almost impossible. You’re competing on UX and distribution against companies that can afford to lose money longer than you can.

Vertical specialization changes the equation. Build deep expertise in one domain. Healthcare AI can charge premium prices because healthcare customers pay for accuracy and compliance. Legal AI commands higher ACVs because the value is clear and the switching costs are real. Financial services, enterprise security, specialized manufacturing and the list goes on and on. The one thing all of these verticals have in common is that they have dollars and pain.

Proprietary data creates real moats.

If you’re training on unique datasets your competitors can’t access, you’re building something defensible. Fine-tuned models that solve vertical problems better than generic models give you pricing power. Integration depth into existing workflows makes switching painful.

The decision is strategic: either charge premium prices through vertical differentiation, or optimize costs through focused specialization. Ideally, do both. Pick a vertical, own it, then expand from strength.

What to Show Investors

Transparency beats optimism in due diligence. Don’t pretend margins will magically improve. Show the path from current state to target state with specific initiatives and timelines.

Your deck needs a margin bridge. Here’s current gross margin, here’s where we’re going, here’s how we get there. Break it down: X percentage points from infrastructure optimization, Y points from pricing changes, Z points from product mix evolution. Give quarters, not hand-waving.

Sensitivity analysis matters. How do margins change as we scale? What happens if inference costs don’t drop as fast as we’re modeling? What if they rise? Show that you’ve pressure-tested the assumptions. Investors won’t believe a straight-line path to 80% margins. Show them the scenarios.

Be honest about which features make money and which lose money. Every AI company has features that are strategic losses. That’s fine. What’s not fine is not knowing which ones they are.

If your analytics tool attracts users but costs $15/month to serve at a $10 price point, own it. Explain why it’s worth the subsidy and when that changes.

Red flags that kill deals:

• “We’ll figure out margins later.”

• “Inference costs will solve themselves.”

• “Everyone in AI has this problem.”

• “We’ll get acquired before profitability matters.”

These are startup suicide notes. Investors have seen this movie. It ends badly.

The Path Forward

This isn’t an argument against AI startups. I run an AI platform. I believe agents will transform how we work. But belief in the technology doesn’t excuse ignoring economics.

The companies that win won’t have the most impressive models. They’ll have the best margins. Success comes from building sustainability into the architecture from day one, not bolting it on after you’ve raised $50 million at prices you can’t support.

Ask yourself these questions:

• Can we reach 60%+ gross margins at scale?

• If not, why are we building software instead of a services company?

• Do we have differentiated value that commands pricing power, or are we selling someone else’s AI with our UX?

• Are we building features that don’t scale linearly with compute costs?

• Do we have a roadmap to improve margins over time with specific initiatives and owners?

If those answers are fuzzy, you’re not ready for institutional capital.

That’s okay. Get ready.

The angel investors raising concerns about AI economics aren’t wrong. They’re right. The question is whether you’re building a company that proves the bears wrong or confirms their thesis. Margin discipline separates the two.

This scrutiny is healthy. It forces rigor.

The AI companies that survive the next funding cycle won’t be the ones that grew fastest. They’ll be the ones that built actual businesses with real unit economics and defensible margins.

Start there.

Visit Moltin

I had spent 11 years building enterprise systems before I started managing the people who build them. That transition taught me something unexpected: the hardest problems in tech aren't technical. They're human.

Now I watch teams struggle with a new kind of friction. It's not about whether AI agents work. It's about whether people trust them enough to work alongside them. We're asking employees to collaborate with systems that don't take coffee breaks, don't have bad days, and occasionally make mistakes they can't explain.

Psychological safety used to mean you could admit errors to your manager without fear. Now it means admitting you don't understand why the algorithm just did what it did. That's a different animal entirely.

Visit Moltin

What Psychological Safety Actually Means in AI-Augmented Teams

Amy Edmondson coined "psychological safety" to describe teams where people feel safe taking risks. They ask questions. They admit mistakes. They challenge ideas without fear of embarrassment or punishment.

Add an AI agent to that team and the definition stretches. Now psychological safety includes feeling safe to question an algorithm’s output. It means admitting you don’t understand how the system reached its conclusion. It means pushing back on automation without looking like you’re resisting progress.

Most teams aren't there yet. A 2025 EisnerAmper study found that 68% of employees regularly find errors in AI outputs, yet 82% remain confident in the technology's accuracy. That's not trust. That's deference, and deference kills learning.

When someone defers to an algorithm they don't trust, they're performing compliance. Real collaboration requires something deeper. It requires believing that questioning the AI won't mark you as incompetent or resistant to change.

The stakes matter here. In traditional teams, psychological safety predicts learning, innovation, and performance. Early research suggests it predicts the same outcomes in human-AI teams, but the mechanisms are different. You can't build rapport with an algorithm over lunch.

The Unique Challenges of Trusting Non-Human Teammates

The Opacity Problem

Humans explain their reasoning when asked. Even when they're wrong, you can usually trace their logic. AI agents often can't or don't.

Large language models operate through billions (now trillions) of parameters. Even the engineers who built them can't always explain specific outputs. This creates an asymmetry. Your human colleague might make bad calls, but you can at least argue with them.

When the AI makes a recommendation you don't understand, you face a choice. Trust it blindly or spend hours trying to reverse-engineer its reasoning. Most people don't have hours. So they either defer or disengage.

This opacity breeds a specific kind of anxiety. People worry they're missing something obvious. They second-guess themselves. Over time, that erodes confidence in their own judgment.

The Accountability Gap

When your colleague drops the ball, you know who to talk to. When an AI agent makes an error, who's responsible? The data scientist who trained it? The product manager who deployed it? The executive who approved the budget?

This ambiguity is corrosive. Research on organizational psychology shows that unclear accountability reduces trust and increases stress. People need to know that someone is responsible when things go wrong.

In most organizations, that someone defaults to the human who relied on the AI's output. Fair or not, you're accountable for decisions made with AI assistance. That reality makes people cautious. They'd rather do it themselves than risk being blamed for an algorithmic error.

The Competence Paradox

Here’s the twist: the better you are at your job, the harder it is to trust AI assistance. Experts have strong mental models. They’ve learned to trust their intuition. When an AI suggests something that conflicts with that intuition, they face cognitive dissonance.

Novices don't have this problem. They don't have enough context to second-guess the algorithm. But novices also can't catch the AI's mistakes. They can't tell when the system is confidently wrong.

This creates a competence paradox. The people best equipped to work effectively with AI are the ones most likely to distrust it. The people most likely to trust it are least equipped to use it safely.

Building Trust Through Transparent System Design

Make the AI’s Confidence Visible

Don't just show the output. Show the confidence interval. When an AI agent makes a prediction or recommendation, users need to see how certain the system is.

We built this into our workflow automation platform after watching users struggle. Instead of “Schedule this meeting for Tuesday at 2pm,” our agents now say “I’m 87% confident Tuesday at 2pm works for everyone. The alternative is Wednesday at 10am.” That small change doubled the rate at which users validated AI suggestions before acting on them.

Confidence scores aren't perfect. But they give people permission to question. They signal that uncertainty is normal and expected.

Provide Reasoning Traces

When possible, show your work. Modern AI systems can't always explain their full reasoning. But they can often highlight what inputs mattered most.

In our document analysis agents, we surface which sections of text drove key conclusions. In our scheduling agents, we show which calendar constraints created conflicts. Users don't need to understand the full model. They need to understand what the model prioritized.

This serves two purposes. It helps users catch errors when the AI weighted the wrong factors. And it helps them learn the system's logic over time, building mental models of how it thinks.

Design for Graceful Failure

Systems that hide their mistakes train users not to check. If an AI agent never admits uncertainty or flags edge cases, people eventually stop verifying its work. They assume silence means correctness. That's dangerous because it breeds complacency right up until a major error slips through.

Systems that acknowledge limitations train users to stay engaged. When an agent says "I'm not confident about this" or "This request is unusual for me," it keeps people alert. It signals that human judgment still matters. Users don't tune out because they know the system will ask for help when it needs it.

We're explicit about what our agents can and can't do. Our document summarization agent handles standard business reports well. But throw it a legal contract with complex conditional clauses? It tells you upfront: "This document type is outside my training. I can give you a basic summary, but you should verify key details with someone who specializes in contracts."

When a task falls outside an agent's capability, it says so and hands off to a human. This happens more often than you'd think. A scheduling agent that can't resolve a three-way conflict between executive calendars shouldn't just pick a random solution. It should surface the conflict, explain why it's stuck, and ask a human to make the call.

This honesty builds trust in multiple ways. First, it demonstrates self-awareness. The system knows what it doesn't know. That's more sophisticated than blindly applying rules regardless of context.

Second, it reduces cognitive load. Users don't have to constantly wonder whether they're in a situation the AI can't handle. The system tells them. That frees up mental energy for actual problem-solving instead of anxiety management.

Third, it creates a partnership dynamic instead of a supervisory one. When the AI acknowledges its limits, it positions the human as a collaborator rather than a quality checker. You're working together to handle edge cases, not constantly auditing for mistakes.

Users learn they can rely on the system to know its limits. That reliability is itself a form of competence. An agent that consistently identifies when it's out of its depth is more trustworthy than one that confidently bulldozes through every scenario.

That makes them more comfortable leaning on it within those limits. Once people know the AI will speak up when it's unsure, they stop second-guessing it on routine tasks. They save their verification energy for the situations that actually need it. The result is faster workflows and less decision fatigue.

Build Feedback Loops That Close Visibly

When someone corrects an AI agent, they need to see that the correction mattered. Think about human relationships. When you give feedback to a colleague and they change their behavior, you notice. That reinforcement makes you more likely to speak up again. The same dynamic applies with AI, but it's harder to perceive.

Nothing erodes trust faster than feeling ignored. If users repeatedly correct an agent's mistakes without seeing any improvement, they draw one of two conclusions. Either the system can't learn, which makes them wonder why they're bothering. Or it won't learn, which makes them feel powerless. Both conclusions lead to disengagement.

Our agents confirm when they've incorporated feedback. When someone corrects a scheduling preference, the agent responds: "Got it. I've updated my understanding that you prefer morning meetings on Tuesdays. I'll apply this going forward." That immediate acknowledgment matters. It closes the loop in the moment instead of leaving people wondering whether their input registered.

But confirmation alone isn't enough. Users need to see evidence that the correction actually changed behavior. So we show them. The next time that agent makes a scheduling decision, it surfaces a brief note: "Based on your previous feedback, I'm prioritizing Tuesday morning slots." That callback demonstrates memory and learning.

This visible learning loop serves multiple purposes.

It proves that human input still matters. People worry that as AI systems get more sophisticated, their judgment will become irrelevant. Seeing their corrections shape future behavior contradicts that fear. It shows them they're teaching the system, not just coexisting with it.

It creates accountability for the AI. When the system explicitly states it learned something, users can evaluate whether it actually applied that learning correctly. If the agent says it learned your Tuesday preference but then schedules you on Wednesday, that discrepancy is obvious. Users can catch regression or misapplication more easily.

It builds institutional knowledge in a visible way. In traditional teams, knowledge transfer happens through observation and documentation. With AI agents, it needs to be explicit. When the system shows how feedback modified its behavior, other team members can see that logic too. They learn not just about the AI's capabilities, but about organizational preferences and priorities embedded in those corrections.

It counters the fear that the AI will eventually make people obsolete. This fear is real and widespread. A 2024 Pew Research Center survey found that "about half of workers (52%) say they're worried about the future impact of AI use in the workplace, and 32% think it will lead to fewer job opportunities for them in the long run." When people see that AI systems depend on their corrections to improve, it reframes the relationship. They're not being replaced. They're becoming trainers, coaches, and quality controllers for increasingly capable tools.

The key is making this learning visible and specific. Generic messages like "Thank you for your feedback" don't cut it. Users need to see exactly what changed and how their input influenced future decisions. That specificity transforms passive users into active collaborators who understand their ongoing role in the system's effectiveness.

Organizational Practices That Foster Safety

Normalize AI Skepticism

Make questioning the algorithm an explicit part of the job. If critical thinking about AI outputs isn't formally valued, people will treat it as optional. They'll default to acceptance because it's faster and feels safer than pushing back.

In our weekly meetings with the various teams across the enterprise, we reserve time for "AI doubt sessions." These aren't complaint forums. They're structured discussions where people share moments when they overrode an agent's recommendation and explain their reasoning. Last week, a product manager described ignoring our pricing optimization agent's suggestion to raise prices on a legacy product. Her reasoning? She knew those customers were price-sensitive early adopters who'd churn if we squeezed them. The AI had the pricing elasticity data but missed the relationship context.

We celebrate those decisions, even when the AI turned out to be right. That's the crucial part. If we only celebrated correct overrides, we'd be punishing good judgment that happened to be wrong. A developer once overrode our code review agent's approval because the solution felt too clever. He rewrote it more simply. Turned out the AI's version would've worked fine, but his instinct to prioritize maintainability was exactly right. We praised the thinking, not just the outcome.

These sessions do several things at once. First, they create public examples of healthy skepticism. New employees see senior people questioning AI outputs and learn that this behavior is expected, not tolerated. There's a difference. Tolerated means you won't get punished. Expected means you're doing your job wrong if you don't do it.

Second, they build a shared library of edge cases. When someone describes a situation where they overrode the AI, others learn to watch for similar patterns. That project manager’s story about relationship context taught the whole team to consider factors the AI can’t see. The next time someone faces a similar decision, they have a mental model to reference.

Third, they surface systematic problems. If multiple people override the same agent for similar reasons, that’s not user error. That’s a training gap or a design flaw. We’ve caught several issues this way. Our document classification agent kept miscategorizing technical specs as marketing materials. Three different people mentioned overriding it in the same month. That pattern triggered a review, and we discovered the agent was over-indexing on formatting instead of content.

This practice signals that skepticism isn’t resistance. In many organizations, questioning automation gets coded as technophobia or resistance to change. People worry they’ll be seen as Luddites if they push back on AI recommendations. By explicitly celebrating doubt, we reframe it. Skepticism becomes diligence, not obstruction.

It gives people language and permission to express doubt. Many employees don’t know how to articulate their concerns about AI outputs. They have a gut feeling something’s wrong but can’t explain why. Hearing colleagues describe their reasoning provides vocabulary. “The AI doesn’t have context about our customer relationships” becomes a legitimate reason to override, not just a vague feeling. “The recommendation optimizes for short-term metrics but misses long-term strategy” becomes expressible concern rather than unspoken anxiety.

Distribute AI Knowledge Broadly

Concentrated expertise creates power imbalances. When only data scientists understand how the AI works, everyone else feels like a passenger. We invest heavily in AI literacy across the organization. Not deep technical training, but enough that people understand concepts like training data, bias, and confidence intervals.

This shared vocabulary makes it easier to have productive conversations about AI limitations. It helps people advocate for their own judgment when it conflicts with algorithmic recommendations.

Establish Clear Escalation Paths

People need to know what to do when they strongly disagree with an AI agent. We created a simple protocol. If you think the AI is wrong, document your reasoning and escalate to your manager or, at the very least, a forward deployment engineer. If the pattern repeats, it triggers a review of the agent’s training data or decision rules.

This process gives people agency. It proves their judgment matters. And it catches systematic problems before they compound.

The Role of Leadership in Modeling Trust

Leaders set the tone. If executives blindly follow AI recommendations, employees will feel pressure to do the same. They’ll assume that questioning the algorithm is career-limiting behavior. If executives never follow AI recommendations, employees will see the systems as theater. They’ll invest minimal effort in learning tools that leadership clearly doesn’t value. The balance matters more than the specific decisions.

I make a point of sharing my own decision-making process with AI tools. In meetings, I’ll say things like “The agent suggested we prioritize Project X, but I’m going with Project Y because it’s missing context about our Q2 roadmap.” That transparency models healthy skepticism. It shows that human judgment still drives strategy. It also teaches people what good override reasoning looks like.

The key is explaining the “why” behind the override. Simply saying “I’m going with Y instead” tells people what you decided but not how to think. Adding the context explanation gives them a framework. They learn that missing strategic context is a legitimate reason to override. Next time they face a similar choice, they have a mental model.

I also share when the AI catches things I missed. Last quarter, our capacity planning agent flagged a resource conflict I’d overlooked. I acknowledged it publicly in our leadership meeting and thanked the engineer who’d set up the alert. That matters too. Leaders who never admit the AI helps them create an unspoken expectation: you should catch everything yourself and only use AI as backup.

That expectation is exhausting and counterproductive. It frames AI assistance as admission of weakness rather than intelligent delegation. When leaders openly credit the AI for valuable catches, it normalizes using these tools as legitimate collaborators. People feel less pressure to appear infallible.

The goal is to demonstrate collaborative intelligence. Human judgment and AI capability complement each other. Neither is sufficient alone. I bring strategic context, organizational memory, and stakeholder awareness that our agents don’t have. They bring data analysis speed, pattern recognition across large datasets, and consistency that I can’t match.

When leaders model that balance, it becomes safer for everyone else to find their own. Your team watches how you interact with AI tools. They notice what you override and what you accept. They pick up on whether you treat the systems as partners or as threats to your authority. Make sure what they’re learning is what you want them to practice.

What This Means for Teams Rolling Out Agentic AI

Start slow with high-stakes decisions. Deploy agents first in contexts where mistakes are cheap. Let people build confidence before automating critical workflows. We began with meeting scheduling and document formatting. Low risk, high frequency, easy to override.

As people learned to trust those agents, we expanded to more complex tasks. By the time we automated parts of our customer support triage, the team had months of positive experience. They’d learned the systems’ quirks. They knew when to double-check and when to let go.

Invest in onboarding that goes beyond feature training. Teach people how the AI makes decisions, what data it relies on, what situations might confuse it. Give them mental models, not just button clicks.

Create space for emotional responses. Some people will feel threatened by AI agents. Some will feel relieved. Some will feel both, depending on the day. Treating those feelings as irrational or resistant makes them fester. Treating them as normal responses to real change helps people process and adapt.

Expect a trust dip before improvement. Initial deployment often decreases psychological safety as people adjust to new workflows. That’s normal. What matters is whether safety rebounds and eventually exceeds baseline. If it doesn’t rebound within three months, you’ve got a design or culture problem that needs addressing.

The Long Game

Building trust between humans and AI isn’t a launch problem. It’s an ongoing practice. The technology will keep evolving. New capabilities will emerge that challenge existing comfort levels.

Teams that treat psychological safety as a permanent priority will adapt better than teams that treat it as a one-time implementation concern. This requires sustained attention from leadership, continuous investment in transparency and education, and genuine willingness to slow down when trust erodes.

The companies that get this right won’t just have more productive AI deployments. They’ll have more resilient organizations. When humans trust their AI teammates enough to question them, everyone gets smarter.

That’s the goal. Not blind faith in algorithms. Not fearful resistance to automation. But genuine collaboration between human and machine intelligence, grounded in mutual respect and clear accountability.

Your AI agents are only as good as the trust your team has in them.

Visit Moltin

Your AI agent bill just tripled last month. You're not alone. While token prices have dropped over 99% since 2023, overall AI spending keeps climbing (Jevons Paradox strikes again!). The culprit isn't the price per token. It's how many tokens your architecture burns to get anything done.

This is the hidden tax of agentic AI. You thought you were building cost-efficient automation. Instead, you built a token incinerator.

Here's what the numbers actually tell us. Token usage drives 70% of AI agent expenses, with moderate deployments consuming 5 to 10 million tokens monthly at a cost of $1,000 to $5,000 according to Azilen. But that's just the API bill. The real damage happens when you scale.

A developer shared their experience on Reddit ("Spent 9.5B OpenAI tokens in January") revealing they burned through 9.5 billion tokens in January 2025. After analyzing usage patterns, optimizing prompts, and switching to GPT-4o-mini with caching enabled, they achieved a 70% reduction in output tokens and a 40% overall cost decrease according to a case study by Evalics.

That's the difference between a sustainable business and a cash bonfire.

Visit Moltin

Why Your Token Math Is Wrong

Most teams calculate costs like this: take the model price per million tokens, multiply by expected volume, done. That math works for simple API calls. It fails spectacularly for agentic workflows.

Your demo chatbot says "Your bill is $X" using 200 tokens. Your production bot thinks through payment history, customer tier, previous complaints, billing system verification, tone guidelines, then provides the same answer. Same output, 26,200 tokens. Your cost model just broke.

According to Dataiku's analysis "The Agentic AI Cost Iceberg," production AI systems can use 6x the tokens of demo systems for the same answer, with the 200-token demo response becoming a 1,200-token production interaction. This token inflation isn't a bug. It's the cost of reliability.

The problem compounds with agentic workflows. Models like o3, DeepSeek R1, Grok 4, and Kimi K2 introduced multi-step processes that caused token consumption per task to jump 10x to 100x since December 2023 according to Adam Holter's analysis "AI Costs in 2025: Cheaper Tokens, Pricier Workflows."

You're not paying for answers anymore. You're paying for thinking.

Single-Agent vs. Multi-Agent Economics

Here's where architecture decisions get expensive. A single-agent system handles everything through one model. Simple, predictable, cheap. A multi-agent system splits work across specialized agents. Complex, powerful, potentially ruinous.

The math seems straightforward. According to Khushbu Shah's analysis "Single Agent vs Multi Agent in AI: What Your Project Hinges On" published on ProjectPro, single-agent systems scale costs linearly with task complexity, making them cost-efficient for startups and projects with narrow scopes. But that linear scaling hits a wall fast.

Try building customer support with a single agent. It handles FAQs fine. Then someone asks about returns for a damaged product bought with a promotion that expired. Your single agent needs the full context of your return policy, promotion terms, inventory system, and customer history. Every query burns thousands of tokens retrieving information it might not need.

Multi-agent systems fix this through specialization. One agent handles returns, another manages promotions, a third checks inventory. Each carries less context. You can lower costs by using cheaper models for most agents and reserving expensive ones for important tasks.

BNY Mellon deployed a multi-agent system called Eliza where 13 specialized agents handle financial workflows autonomously. According to VentureBeat's analysis "How big U.S. bank BNY manages armies of AI agents," these agents range from client agents to segment agents, and they "negotiate with each other" to determine product recommendations based on marketing segments. Each agent performs domain-specific tasks like document parsing or knowledge retrieval. The result? Better efficiency and scalability than dumping everything into one massive context window.

But multi-agent systems aren't free money. They require orchestration, monitoring, and careful design. Development costs are higher. Maintenance is harder. You're trading API costs for engineering time.

Here's the decision framework. Use single agents when you're prototyping, handling narrow tasks, or operating with limited engineering resources. Switch to multi-agent when domain specialization matters, cross-functional coordination is required, or future scalability justifies the upfront investment.

The Token Efficiency Multiplier

Retrieval-Augmented Generation fundamentally changes the economics. Instead of stuffing your entire knowledge base into every prompt, you fetch only relevant information.

The token savings are large.

Traditional RAG splits documents by token count. Every 1,000 tokens becomes a chunk. This is simple and terrible. It breaks context mid-sentence, duplicates information across chunks, and forces you to retrieve more pieces to get complete answers.

Context-aware RAG fixes this. According to Microsoft's technical article "Context-Aware RAG System with Azure AI Search to Cut Token Costs and Boost Accuracy," their implementation using Azure AI Search achieved an 80 to 85% reduction in token usage while improving both accuracy and response speed. Instead of fixed-size chunks, it creates semantically complete segments. Your retriever pulls fewer pieces. Your LLM processes less noise.

The savings scale brutally. A Cambridge University study titled "Maximizing RAG efficiency: A comparative analysis of RAG methods" found that different RAG methods produced dramatically different results. The Refine method resulted in an 18.6% reduction in token usage, while the Reciprocal method demonstrated a 12.5% reduction. Your choice of RAG architecture isn't a detail. It's a line item.

But RAG introduces its own costs. You’re paying for embeddings, vector storage, and retrieval operations. OpenAI charges around $0.10 per million tokens for embeddings, while Google Gemini charges $0.15 per million input tokens according to Net Solutions. Those costs accumulate silently.

The break-even calculation matters. If you’re answering one-off questions with constantly changing data, RAG might cost more than just using a larger context window. If you’re handling thousands of queries against the same knowledge base, RAG crushes the competition.

The Hidden Multiplier: Reasoning Tokens

Here's what most teams miss. Newer models like GPT-o1, DeepSeek R1, and Claude Opus don't just generate answers. They generate reasoning. Those thinking tokens are billed as output tokens, which cost 2x to 5x more than input tokens.

Grok 4 costs $3 per million input tokens and $15 per million output tokens. Looks reasonable. Turn on reasoning and it can effectively cost 3x Sonnet with thinking enabled, and nearly 15x without according to cost analysis. Your "efficient" model choice just became your most expensive one.

This is the 2026 cost trap. Reasoning models are better. They handle complex tasks with fewer retries. They need less hand-holding. But they burn tokens like crazy to do their thinking. If you don't need the reasoning capability, you're subsidizing intelligence you don't use.

The optimization here is rough as well. Treat reasoning settings like a spending dial. Use reasoning for complex decisions, planning, and multi-step workflows. Turn it off for simple queries, data formatting, and straightforward transformations. Your bill will thank you.

Practical Success Metrics That Actually Matter

Forget cost per token. That number means nothing without context. What matters is cost per successful outcome. Did the agent complete the task? Did it require human intervention? How many tokens did it burn getting there?

For example, a financial services firm tracks "cost per resolved ticket." Their single-agent support bot costs $0.15 per interaction. Their multi-agent system costs $0.32. But the multi-agent system resolves 40% more tickets without escalation. Cost per successful resolution? Multi-agent wins.

E-commerce companies measure differently. They track cost per completed order, cost per product recommendation that converts, cost per abandoned cart recovered. Dahbahm Digital Media, a digital agency specializing in AI automation, deployed AgentiveAIQ agents across 15 client stores. According to their case study, they achieved a 73% drop in tier-1 support tickets and recovered 25% of abandoned carts within weeks. The token costs became irrelevant.

Your metrics should reflect your business model. B2B SaaS platforms might track cost per qualified lead generated. Customer support operations measure cost per ticket resolved. Internal tools calculate cost per automation completed. Pick the metric that ties to revenue or savings.

Then optimize ruthlessly. Profile your token usage. Find the expensive operations. Replace GPT-4 with GPT-3.5 for simple tasks. Implement caching for repeated queries. Use RAG instead of long contexts. Switch to cheaper models for non-critical paths.

The Architecture Decision Tree

You can't build cost-effective agent systems without a framework. Here's how to think through the choices.

Start with scope. Is this a narrow, well-defined task? Single agent, simple tools, minimal context. Is it a complex workflow spanning multiple domains? Multi-agent with specialized roles and orchestration.

Consider data characteristics. Static knowledge base that rarely changes? Long context windows might work. Dynamic data that updates constantly? RAG architecture. Massive corpus that never changes?

Fine-tuning might be cheaper long-term.

Evaluate query patterns. One-off questions from users? Pay per query with stateless agents. Ongoing conversations with memory? State management costs matter. Batch processing?

Optimize for throughput over latency.

Look at scale. Thousands of queries per day? Caching and optimization are mandatory. Millions? You need dedicated infrastructure and cost monitoring. Billions? You're building custom solutions and negotiating enterprise pricing.

Factor in engineering capacity. Small team? Simple single-agent architecture with managed services. Experienced team? Multi-agent with custom orchestration. Limited ML experience?

Stick to frameworks and pre-built tools.

The Economic Reality

Token prices keep falling. A 2025 Berkeley model reproduced a similar model to one that cost an estimated $100 million for only $30 of compute according to Monetizely. That's a 99.99% cost reduction. You'd think AI would be getting cheaper.

It's not. Because we're using AI differently. We went from simple completions to multi-step reasoning. From static prompts to dynamic agent workflows. From dozens of tokens to thousands per task. The price per token dropped. The tokens per task exploded.

This creates a weird dynamic. The companies winning on costs aren't the ones using the cheapest models. They're the ones building architectures that minimize wasted tokens. They cache aggressively. They route intelligently. They measure obsessively.

The lesson is clear. In 2026, architectural choices matter more than model prices. You can use the most expensive model and still come out ahead if your architecture is efficient. Or you can use the cheapest model and go bankrupt if you're burning millions of wasted tokens.

Build for Efficiency, Not Just Intelligence

The smartest agent isn’t always the most profitable one. Sometimes the dumbest solution that works is the one that scales.

Consider classification tasks. You could use GPT-4.5 to categorize customer emails. It’ll be incredibly accurate. It’ll also cost you $0.07 per 1,000 tokens. Or you could use a fine-tuned BERT model that costs effectively nothing after training. It’ll be 95% as accurate and 100x cheaper.

The same logic applies to agent architectures. You could build a sophisticated multi-agent system with planning, reflection, and self-correction. It'll handle edge cases beautifully. It'll also burn tokens on every interaction. Or you could build a simple single-agent system with good error handling. It'll cover 80% of cases for 20% of the cost.

This isn't about dumbing down your AI. It's about right-sizing intelligence to the problem. Use expensive reasoning for expensive problems. Use cheap classification for cheap problems.

Don't bring an Opus to a Haiku fight.

The developers who master this will build sustainable AI agentic systems. The ones who chase capabilities without watching costs will build expensive science experiments.

Your token budget is your product strategy. Spend it wisely.

Visit Moltin

Most companies treat AI like a fancy calculator. They bolt it onto existing workflows, call it innovation, and wonder why nothing changes. That's not integration. It's decoration.

Real AI maturity means rethinking how work gets done. Not adding smarter tools to the same old processes, but letting AI reshape those processes entirely. The difference between these approaches isn't subtle. It's the difference between hiring a contractor and hiring a partner.

Visit Moltin

Stage One: AI as a Tool

This is where everyone starts. You're using AI to automate repetitive tasks. Data entry. Basic classification. Scheduled reports. The AI does what you tell it, when you tell it, exactly how you tell it.

It's useful. It saves time. But it doesn't think.

You still own every decision. The AI waits for instructions. If something unexpected happens, it stops and asks what to do. This is fine for simple, predictable work. It falls apart the moment things get complex.

The real limitation isn't technical. It's that you're still doing all the cognitive heavy lifting. You're just typing less.

Here's what this looks like in practice. Your marketing team uses AI to generate social media posts from blog content. Great. But someone still needs to decide which blog posts to promote, when to post them, what tone to use, and whether the output actually makes sense. The AI is a faster typist. Nothing more.

Or take data analysis. You've got an AI that can run SQL queries and generate charts. Wonderful. But you're still the one deciding which questions to ask, which metrics matter, and what the numbers actually mean. The AI executes. You strategize. You interpret. You connect dots.

This is where the "you're just typing less" problem becomes obvious. Let's say you're processing customer feedback. Your Stage One AI can categorize 10,000 comments into buckets: positive, negative, feature request, bug report. It does this in minutes instead of days. That's real value.

But here's what it can't do. It can't tell you that the uptick in negative sentiment correlates with a specific feature you shipped two weeks ago. It can't notice that your power users are asking for different things than your casual users. It can't flag that three seemingly unrelated complaints are actually symptoms of the same underlying issue. You have to do that work. You have to look at the categorized data and figure out what it means.

The AI compressed your timeline. It didn’t compress your cognitive load. You’re still the bottleneck for every insight, every decision, every next step.

This creates a weird trap. You feel more productive because you're processing more data faster. But you're not actually making better decisions faster. You're drowning in AI-generated output that still requires human interpretation. Instead of 100 data points you can't analyze, you now have 10,000 you can't analyze.

Congratulations?

The other problem is brittleness. Stage One AI only works when conditions match its training. Show it something new and it chokes. A customer writes a complaint using sarcasm? The sentiment classifier tags it as positive. Someone submits a form with an unexpected format? The data entry bot throws an error and waits for you to fix it manually.

You end up babysitting the AI. Checking its work. Handling exceptions. Building more and more rules to cover edge cases. At some point, the overhead of managing the AI rivals the work it was supposed to eliminate.

None of this means Stage One is useless. It's not. For well-defined, high-volume, low-variability tasks, it's perfectly fine. Transcribing audio. Extracting text from invoices. Resizing images. These are problems where the input is predictable and the output is obvious.

But most knowledge work isn't like that. Most work requires judgment calls, context switching, and dealing with ambiguity. Stage One AI can't help you there. It can make you faster at the mechanical parts. It can't make you smarter at the hard parts.

Stage Two: AI as a Teammate

Here's where it gets interesting. The AI starts making decisions within boundaries you've set. It doesn't just execute tasks. It figures out how to execute them.

Let's say you're running customer support. Stage One AI might categorize tickets. Stage Two AI reads the ticket, checks your knowledge base, drafts a response, and sends it if it's confident. If it's not, it escalates to a human with context already attached.

You're still in charge. But you're no longer micromanaging every step. The AI handles the 80% of cases that follow patterns. You focus on the 20% that need judgment, empathy, or creative problem-solving.

This is where most organizations should be aiming right now. It requires trust, which means it requires good data and clear guidelines. You can't just flip a switch. You need to teach the AI what good looks like, then gradually expand what it's allowed to handle on its own.

The shift here is psychological as much as technical. You're moving from "AI does tasks" to "AI does jobs."

Think about what changes when AI operates at this level. It's not waiting for you to tell it the next step. It's chaining actions together based on context. A customer asks about a refund? The AI checks their order history, verifies the purchase is within the return window, calculates the refund amount, initiates the transaction, and sends a confirmation email. One request, six actions, zero human touches. That's not automation. That's delegation.

The difference shows up most clearly when things don't go according to plan. Stage One AI hits an exception and stops. Stage Two AI hits an exception and adapts. Maybe the refund amount doesn't calculate correctly because of a partial return. The AI recognizes this is outside its confidence threshold, escalates to a human agent, and includes everything it already checked so the agent doesn't start from scratch. The AI understood the goal, made progress toward it, and knew when to ask for help.

Building this takes more than better models. You need clean data pipelines so the AI has accurate information to work with. You need explicit rules about what the AI can decide on its own versus what needs human approval. You need monitoring systems that flag when the AI is making mistakes or operating outside expected parameters. Most critically, you need feedback loops so the AI learns from corrections and gets better over time.

Here’s what that looks like in practice. Your AI drafts 100 customer responses and sends them. A human reviews a random sample and marks three as tone-deaf or factually wrong. That feedback goes back into the training data. Next week, the AI makes those same mistakes less often. Next month, barely at all. You’re not babysitting anymore. You’re coaching. The AI is actively getting better at its job, not just executing the same script faster.

The ROI at this stage isn’t just about speed. It’s about leverage. One person can oversee work that used to require a whole team. But that person’s role changes completely. They’re not doing the work anymore. They’re setting strategy, handling edge cases, and improving the system. If you’re still hiring for “executor” roles when you’ve got Stage Two AI, you’re doing it wrong. You need curators, troubleshooters, and trainers instead.

Stage Three: AI as an Autonomous Peer

This is the frontier. The AI doesn’t just make tactical decisions. It makes strategic ones. It identifies problems you haven’t noticed yet. It proposes solutions you wouldn’t have thought of. It operates with minimal oversight because it understands not just the rules, but the reasons behind them.

Imagine an AI that monitors your entire data pipeline. It doesn't wait for you to notice a performance issue. It spots the pattern, diagnoses the cause, tests a fix in a sandbox environment, and deploys it. Then it tells you what it did and why.

Or think about a sales AI that doesn't just qualify leads. It analyzes which markets you're underperforming in, hypothesizes why, suggests new messaging, and runs A/B tests to validate its ideas. You review the results and approve the winner. But the AI did the thinking.

This isn't science fiction. The technology exists. What's missing is organizational readiness.

Stage Three requires you to let go of control in ways that feel uncomfortable. You need robust monitoring systems. You need clear boundaries around what the AI can and can't do autonomously. Most importantly, you need a culture that's okay with AI making mistakes, because it will. Just like humans do.

The hardest part isn't technical. It's trusting an AI to operate in domains where mistakes have real consequences. When your data pipeline AI decides to restructure your indexing strategy, what happens if it's wrong? When your sales AI pivots your messaging in a key market, what if it misread the data? These aren't hypotheticals. They're the exact fears that keep most organizations stuck at Stage Two.

But here's the thing. You already trust humans to make these calls.

Your senior engineer doesn't ask permission before optimizing a query. Your sales director doesn't run every messaging change past you. They have the authority to act because they've demonstrated judgment. Stage Three AI is the same deal. You grant it autonomy gradually, based on demonstrated competence. You don't wake up one morning and hand over the keys to the kingdom.

What separates Stage Three from Stage Two is initiative. Stage Two AI responds to requests and handles workflows you've defined. Stage Three AI identifies opportunities and proposes new workflows you haven't thought of yet. It's not just executing your strategy. It's contributing to it.

An inventory management AI notices that stockouts correlate with specific weather patterns and proactively adjusts ordering algorithms. A content AI sees that articles published on Tuesday mornings get 40% more engagement and restructures the editorial calendar without being asked. These aren't tasks you assigned. They're insights the AI surfaced and acted on.

The governance model has to evolve too. You can't review every decision an autonomous AI makes, that defeats the purpose. Instead, you define boundaries and audit outcomes. The AI can spend up to $10K on infrastructure changes without approval. It can't touch customer data without logging every access. It must explain any decision that affects revenue by more than 5%. You're not pre-approving actions. You're setting guardrails and checking that they hold.

This is where the "culture that's okay with mistakes" part becomes critical. Your autonomous AI will screw up. It'll optimize for the wrong metric. It'll miss context a human would've caught. It'll make a technically correct decision that's politically tone-deaf. When that happens, your organization's reaction determines whether you can actually operate at Stage Three. If every mistake triggers a lockdown and a return to manual approvals, you're not ready. If mistakes trigger a debrief, a guardrail adjustment, and a clear path forward, you might be.

What Maturity Actually Looks Like

The maturity model isn’t a ladder you climb once. Different functions in your organization will be at different stages. Your customer support might be at Stage Two while your data engineering is still at Stage One. That’s fine. It’s even expected.

What matters is intentionality. Are you clear about where each function is and where it should be going? Are you investing in the infrastructure, the training, and the cultural change needed to get there?

Most companies aren’t. They’re still treating AI like a feature to check off. They want the benefits of Stage Three with the effort of Stage One. It doesn’t work that way.

The organizations that win won’t be the ones with the fanciest AI models. They’ll be the ones who figured out how to actually integrate those models into the way they work. Who built systems where AI and humans complement each other instead of competing. Who got comfortable with the idea that sometimes the best decision-maker in the room isn’t a person.

That’s not a future state. That’s a decision you can make today. The question is whether you’re willing to do the work to get there.

Visit Moltin

Your AI agent can answer questions. So can everyone else's.

The real edge isn't in the model you picked or how many tokens you're burning. It's in how well your system understands what connects to what. Most companies are building agents that treat every request like it's the first time they've met you. That's expensive, and it shows.

Visit Moltin

The Hidden Cost of Starting from Zero

Every API call costs money. Every hallucination costs trust. And every time your agent asks a user to repeat information it should already know, you're bleeding both.

Let's do the math. Say your agent handles 10,000 queries a day. If 30% of those need to retrieve context before answering, you're making 3,000 retrieval calls plus 10,000 inference calls. That's 13,000 paid operations daily, around 400,000 per month.

Now imagine half those queries are asking about things your system should already know.

• "What's the status of my request?"

• "Who approved this?"

• "What's our policy on X?"

Your agent doesn't remember the org chart. It doesn't remember what happened yesterday. So it searches a document store, retrieves five chunks that might be relevant, sends them to the LLM, and hopes for the best.

Sometimes it works. Sometimes it hallucinates a confident answer based on a partial match. Sometimes it tells your VP that their direct report is someone they've never met because the embeddings were close enough.

Traditional RAG systems retrieve documents based on keyword similarity. They're playing a matching game. "Find me things that look like this query." It works until it doesn't, and it doesn't whenever context matters more than keywords.

Here's the thing: most business questions aren't about finding a document. They're about understanding relationships. Which customer owns this account? What approvals does this workflow need? Who changed this setting last Tuesday? Why did this request get routed to Legal instead of Finance?

A keyword search gives you documents that mention "Legal" and "Finance." A graph gives you the actual routing rule, the person who configured it, and the three requests that followed the same path. One is a scavenger hunt. The other is an answer.

You can't keyword-search your way to those answers. You can retrieve 100 documents and hope the LLM pieces it together. But you're paying for retrieval, you're paying for inference on bloated context windows, and you're praying the model doesn't confidently invent the parts it couldn't find.

That’s not an architecture. That’s expensive guesswork.

Graph Structure Isn’t Just Storage, It’s Memory

A graph database doesn't just store facts. It stores how facts relate to each other. That's not a technical distinction. It's an economic one.

Think about how a traditional system answers "Can this user approve purchases for the EMEA (Europe, Middle-East, Africa) sales team?" It searches for the user's profile document. Then it searches for their role permissions. Then it searches for org structure to confirm they manage EMEA. Then it searches for purchase approval policies. Four separate retrievals, each with its own latency and cost, then you're stuffing all that context into an LLM prompt and asking it to reason about whether the chain holds up.

With a graph, you traverse the relationships directly. User → manages → EMEA Sales. EMEA Sales → requires approver with → Director role. User → has role → Director. The path either exists or it doesn't. One query, sub-100ms, deterministic answer.

When your agent knows that Customer A reports to Manager B who approved Budget C, it doesn't need to re-derive that chain every time. The structure is the answer. One query replaces five.

Here's what that means in dollars. Let's say each document retrieval costs you $0.001 and each LLM inference with a stuffed context window costs $0.01. Your RAG approach: 4 retrievals plus 1 inference equals $0.014 per query. Your graph approach: 1 graph query at $0.0001 plus a lean inference at $0.003 equals $0.0031 per query.

That's 4.5x cheaper per query. Scale that to a million queries and you've saved $10,000…per month. And that's before you factor in the cost of fixing mistakes or the revenue you lose when your agent is too slow.

Cut your inference costs. Cut your latency. Cut the number of times your agent confidently tells someone the wrong thing because it couldn't connect the dots. Graph structure doesn't just make your agents smarter. It makes them economically viable at scale.

Context Compounds

Here's where it gets interesting. The more your graph knows, the smarter every query gets. Not because you're training anything. Because you've encoded the relationships that matter.

This is the part most companies miss. They think context is about retrieval volume. Throw more documents at the LLM and hope it figures things out. But context isn't about quantity. It's about connection density.

Add a new customer to your system. In a document-based world, you've got a customer record sitting in a file somewhere. Your agent can retrieve it. Great. But does it know that customer belongs to the Healthcare vertical? That Healthcare clients typically start with Product A before upgrading to Product B? That deals over $50K in Healthcare require VP approval because of compliance requirements you put in place eight months ago?

Not unless you've written all that in a document and your retrieval system happens to find it. And even then, the LLM has to infer the connections.

In a graph, you've modeled those relationships explicitly. Customer → belongs to → Healthcare vertical. Healthcare vertical → typical purchase path → Product A, then Product B. Healthcare vertical → approval rules → VP required over $50K. Your agent inherits that knowledge instantly. No retrieval lottery. No inference guesswork.

Add a new customer? The graph already knows which team owns that vertical, what products they typically buy, and who needs to approve deals over $50K. Your agent inherits that knowledge instantly.

Now scale that. Every new hire you add connects to a team, a manager, a set of permissions. Every product links to documentation, pricing tiers, or compatible integrations. Every support ticket ties to a customer, an account rep, a product version, and a resolution path.

You’re not storing thousands of disconnected facts. You’re building a knowledge fabric where every node amplifies every other node. When someone asks “Why did this deal stall?” your agent can traverse customer → account rep → approval chain → stuck at Director who’s been out since Monday → auto-escalation rule should have fired but didn’t because it was configured before the org restructure.

Scale that across thousands of entities and millions of edges. Now your AI isn’t just answering questions. It’s reasoning about your business the way your best employees do. The ones who’ve been there for years and just know how everything connects.

Except your graph doesn’t forget. It doesn’t leave for a competitor. And it answers in milliseconds, not meetings.

Why Your Competitors Will Stay Flat

Most companies are optimizing prompt engineering. They’re A/B testing system messages and hoping GPT-5 fixes their problems. That’s like buying a faster horse when everyone else is building railroads.

Graph structure is hard to build and harder to replicate. It requires domain knowledge, data hygiene, and actual thought about what relationships matter. You can’t copy-paste it from a tutorial.

Once you’ve built it, every interaction makes it more valuable. Your agents get smarter. Your users get faster answers. Your costs go down while your competitors are still burning budget on retrieval experiments that return the wrong PDF.

The Boring Truth About Moats

A competitive advantage isn’t always sexy. It’s usually just something valuable that’s annoying to build.

Graph structure is annoying to build. You have to model your domain. Clean your data. Maintain consistency as things change. Most companies won't bother because it feels like plumbing work.

Let's be honest about what this takes. You can't just dump your database into a graph and call it done. You need to actually think about what entities matter in your business and how they relate. Is a "project" connected to "customers" or to "accounts" that belong to customers? Does a "user" have permissions directly or through roles? What happens when someone moves teams?

These aren't technical questions. They're business questions. And getting them wrong means your graph returns garbage.

Then there's the data cleanup. Your CRM says the account owner is "John Smith." Your billing system says "J. Smith." Your support tickets say "John S." Are those the same person?

Probably.

But "probably" doesn't cut it when your agent is making decisions. You need entity resolution, deduplication, and a process for handling conflicts when they inevitably pop up.

And here’s the part that makes most teams quit: maintenance. Your business changes. People leave. Orgs restructure. Products get deprecated. Approval rules get updated. Every change needs to flow into your graph, or it starts lying to you. You need pipelines, validation, and someone who actually cares when things drift out of sync.

None of this is glamorous. There’s no blog post titled “How We Built a Sick ETL Pipeline and You Won’t Believe What Happened Next.” There’s no demo day where investors clap because your entity resolution logic is airtight.

It’s plumbing. Necessary, invisible, boring plumbing. The kind of work that doesn’t go viral on LinkedIn but determines whether your agents actually work six months from now.

Most companies skip it. They’d rather spend another sprint on prompt optimization or try the newest embedding model. That stuff is easy to pitch. “We upgraded to GPT-5 and our agents are 10% better!” sounds way better than “We spent a quarter modeling our domain properly.”

But that’s exactly why it’s a moat. The hard, boring work that everyone knows they should do but most won’t? That’s where you build something defensible.

That’s exactly why it’s a moat.

Your agents aren’t better because you found a secret prompting technique. They’re better because they know things, and they know how those things connect. That’s not a feature you can ship next quarter. It’s infrastructure that pays dividends for years.

Economics, Not Magic

Strip away the hype and agentic AI is just software that makes decisions. The quality of those decisions depends entirely on the quality of the context you provide.

You can keep feeding your agents 50-page documents and hoping they find the right paragraph. Or you can give them a map of what matters and let them run.

One approach scales linearly with your RAG budget. The other scales with your business. The companies that figure this out early won’t just have better agents. They’ll have fundamentally lower costs and faster execution.

And in six months when everyone’s running the same frontier model, that’ll be the only difference that matters.

Visit Moltin

Your company just deployed fifteen AI agents. Three of them work. Two contradict each other daily. The rest keep asking for permission to do things you already approved.

This isn't a technology problem. It's an org chart problem.

Most companies treat AI agents like they treated early cloud deployments: let every team spin up what they need and hope it works out. That approach created shadow IT nightmares in 2012. It'll create shadow AI nightmares now, except faster and with customer or sensitive data involved.

You need an Office of AI Operations. Not another committee. Not a steering group that meets quarterly. A real team with actual authority and a clear mandate.

Visit Moltin

Why Traditional IT Structures Can't Handle This

Your existing IT org wasn't built for systems that learn and change behavior. Help desk tickets assume the software works the same way today as it did yesterday. Change management processes assume you know exactly what the change will do.

AI agents break both assumptions.

An agent that handles customer inquiries learns from every conversation. Its behavior in March won't match its behavior in January. Your standard ITIL framework doesn't have a playbook for "the system got better at its job, but now it's recommending products we discontinued."

Development teams evaluate static code. Agents generate their own actions based on training data you didn't write. The old penetration testing methods won't find prompt injection vulnerabilities.

Compliance officers need audit trails that explain decisions. Most agents today can't tell you why they routed a support ticket to the escalation queue instead of the standard queue. They just did it, and it seemed right based on their training.

What an Office of AI Operations Actually Does

The Office of AI Operations sits between your technical teams and your business units. It's not traditional IT. It's not a product team. It's the group that makes sure your agents work together and don't accidentally work against each other.

Think of it as air traffic control for AI. Every agent needs flight clearance before it goes live. Every agent reports its position. When two agents want to access the same customer data, someone coordinates who goes first.

This office owns three core functions: governance, orchestration, and optimization. Governance sets the rules. Orchestration makes sure agents follow them. Optimization figures out which agents actually drive value and which ones just burn API credits.

You'll also need agent lifecycle management. That means knowing which agents exist, what they're trained to do, when they were last updated, and who's responsible when they screw up. If that sounds like basic asset management, you're right. But most companies can't even answer "how many agents are we running" today.

The Core Roles You Actually Need

Start with an AI Operations Director. This person reports to the CIO or CTO, not buried three levels down in IT. They need budget authority and the power to shut down agents that pose risk. If they can't do both, they're a coordinator, not a director.

You need Agent Reliability Engineers. Not prompt engineers. Not data scientists who took a weekend course on LLMs. People who understand production systems, monitoring, and incident response. When an agent starts hallucinating prices at 2 AM, these folks get paged. They need to know how to roll back, isolate, and fix it before your customer success team melts down.

Hire an AI Ethics and Compliance Lead. Yes, this sounds like corporate overhead. It's not. This person keeps you out of lawsuits and regulatory crosshairs. They review training data for bias. They make sure your agents don't discriminate. They document everything so you can prove due diligence when the auditors show up.

Add Agent Performance Analysts who actually measure what your agents accomplish. Not vanity metrics like "number of interactions." Real metrics: Did the agent solve the problem? Did it reduce handle time? Did customers have to ask a human anyway? These analysts tell you which agents to expand and which ones to retire.

Finally, bring in Integration Engineers who connect agents to your existing systems. They're not building the agents. They're making sure agents can access your CRM, your ERP, your data warehouse, and all the other systems they need without creating security holes or data swamps.

Reporting Structure That Prevents Turf Wars

Your Office of AI Operations can't report to the head of engineering. Engineers will optimize for technical elegance, not business outcomes. It can't report to the head of product either. Product teams will want agents that ship fast, not agents that are safe and compliant.

The office reports directly to the CIO or a peer executive. This keeps it neutral. Business units request agents. Product teams build them. The Office of AI Operations decides if they go live and under what constraints.

Create an AI Operations Review Board with representatives from legal, security, compliance, product, and engineering. This board doesn't design agents. It reviews them before deployment and sets policies the Office of AI Operations enforces. Meet monthly, not weekly. You want oversight, not bureaucracy.

Give business unit leaders clear escalation paths. When they think the Office of AI Operations is blocking something important, they need a way to appeal that doesn't involve hallway arguments or email chains. Define that process up front.

Setting Up Governance Without Creating Red Tape

Good governance feels invisible when things work and catches problems before they metastasize. Bad governance makes people route around it.

Start with an agent registry. Every agent gets documented before deployment: what it does, what data it accesses, what decisions it can make, who owns it. This isn't a spreadsheet. It's a system of record with APIs and automation. If someone deploys an agent that's not in the registry, alarms go off.

Define decision boundaries for each agent type. Customer service agents can issue refunds up to $500. They can't change account ownership. Sales agents can schedule meetings. They can't commit to custom pricing. Document these boundaries and enforce them technically, not just in training data.

Implement continuous monitoring that tracks agent behavior against those boundaries. When an agent tries to do something outside its lane, flag it. Review the flags weekly. Some will be legitimate edge cases. Others are signs the agent is drifting or someone's trying to use it for unintended purposes.

Create templates for common agent types. If three teams want customer service agents, they shouldn't each build from scratch. Give them a pre-approved template with built-in compliance, security, and monitoring. They customize the responses, not the architecture.

Making Agents Work Together

Your HR agent schedules interviews. Your recruiting agent sources candidates. Your calendar agent books conference rooms. Without orchestration, they'll double-book the conference room, schedule the candidate during a company holiday, and send three different emails about the same interview.

Agent orchestration means defining workflows where multiple agents hand off work cleanly. The recruiting agent finds a candidate and passes their info to the HR agent. The HR agent coordinates with the calendar agent. The candidate gets one email from one system, even though three agents were involved.

Build an agent mesh, not point-to-point connections. Agent A shouldn't call Agent B directly. They should communicate through a central orchestration layer that logs every interaction, applies business rules, and handles failures gracefully.

Set priorities when agents compete for resources. If your financial close agent and your customer service agent both want to query the same database, the financial close agent wins during month-end. Document these priorities and enforce them automatically.

Create circuit breakers for agent-to-agent interactions. If Agent A calls Agent B fifty times in ten seconds, something's wrong. Break the circuit. Log it. Alert someone. Don't let a runaway loop take down your whole agent ecosystem.

Measuring What Matters

Most companies track the wrong metrics for AI agents. They count interactions, response times, and uptime. Those numbers look good in executive dashboards and mean almost nothing.

Measure task completion rates. Did the agent solve the problem end-to-end, or did a human have to step in? Track this per agent and per task type. You'll quickly see which agents work and which ones are expensive chatbots.

Calculate cost per outcome, not cost per query. Your customer service agent handled 10,000 chats this month. Great. How many customers actually got their issues resolved? How much would those resolutions have cost with human agents? That's your ROI.

Monitor error rates and error types separately. An agent that fails 1% of the time sounds acceptable. But if those failures all happen during checkout and cost you sales, that 1% matters a lot. Categorize errors by business impact, not just frequency.

Track human override rates. When employees consistently override or correct an agent's decisions, that agent needs retraining or retirement. This metric catches agents that look good statistically but frustrate the people who use them daily.

Building the Team Without Hiring an Army

You don't need fifteen people on day one. Start with three: an operations director, one reliability engineer, and one analyst. That's enough to establish governance, monitor your first production agents, and prove the office adds value.

Hire the operations director first. They'll define the initial policies and make the case for resources. Look for someone who's managed production systems at scale and isn't afraid to tell executives no when necessary.

Your first reliability engineer should come from your existing SRE or DevOps team. They already know your infrastructure and on-call processes. They need to learn AI-specific monitoring and troubleshooting, but they won’t waste months learning how your company works.

The analyst can be junior if you give them good tools and clear metrics to track. They're learning what good agent performance looks like alongside you. As your agent ecosystem grows, add senior analysts who can design experiments and spot trends.

Add specialists only when you feel the pain of not having them or when the use cases require them. If you're spending five hours a week on compliance questions, hire the ethics and compliance lead. If agents keep breaking because they're poorly integrated, bring in an integration architect. Growing the team based on real needs beats building it based on an org chart you saw at a conference.

Common Mistakes That Sink AI Operations Teams

Letting the office become a bottleneck kills its credibility fast. If every agent deployment waits six weeks for review, teams will find ways around you. Build fast-track approvals for low-risk agents using approved templates. Save the lengthy reviews for agents that handle sensitive data or make consequential decisions.

Focusing on governance and ignoring optimization makes you the department of no. Balance is critical. For every policy you enforce, find an efficiency you deliver. Shut down a risky agent in the morning, help a team deploy a better one in the afternoon.

Treating all agents the same wastes everyone's time. A chatbot that answers FAQ questions isn't the same risk as an agent that approves loans. Create tiers: low, medium, and high risk. Match your review depth and monitoring intensity to the tier.

Skipping the feedback loop with business users guarantees you'll solve the wrong problems. Meet with the people who use agents monthly. Ask what's not working. Fix those things before you build new dashboards or write new policies.

Hiring only technical people or only business people creates blind spots. You need both. Technical folks understand what's possible and what's dangerous. Business folks understand what matters and what's theater. Mix the team.

What Success Looks Like Six Months In

Your agent registry has every production agent documented. Anyone in the company can look up what agents exist and who to contact about them. Teams stop building duplicate agents because they can find existing ones.

You’ve prevented at least two incidents that would’ve caused customer impact or compliance problems. The business units grumbled about the delays, but they’re grateful you caught the issues before customers did.

Teams are requesting agents through your defined process instead of asking IT to “spin something up quick.” They see the value in templates and guardrails because deployments are faster and more reliable.

Your metrics show clear ROI for at least half your deployed agents. The other half are in optimization or on track for retirement. You’re not just deploying AI. You’re managing it.

Executives trust your recommendations about which agent initiatives to fund and which ones to kill. You’ve built credibility by being helpful, not just careful.

The Reality Check

Standing up an Office of AI Operations is hard. It requires executive support, budget, and the willingness to tell popular projects no. It creates friction in the short term to prevent catastrophe in the long term.

But companies that skip this step end up with agent sprawl, security incidents, compliance failures, and executive teams that lose faith in AI altogether. The office isn't overhead. It's the difference between AI that scales and AI that becomes a cautionary tale at next year's conference.

Your agents are only as good as your ability to manage them. Build that ability now, while your agent ecosystem is still manageable. Waiting until you have fifty agents in production and three regulatory inquiries means you're building the office under crisis conditions.

Start small. Prove value. Grow deliberately. That's how you create AI operations that actually operate instead of just coordinating meetings about operating.

Visit Moltin

Most AI agents in production look impressive when being written about on LinkedIn. Then they try to execute a three-step workflow and fall apart like a cheap suit.

I've spent the past year watching teams build agents that could dazzle in demos but choked when asked to do anything more sophisticated than answering isolated questions. The problem isn't the models. It's that we're architecting these systems like we're still living in 2022, when a single LLM call was the height of sophistication.

The gap between proof-of-concept and production-ready isn't about finding better models. It's about understanding when your agent needs to think step-by-step, when it needs to react instantly, and when it needs to explore multiple paths before committing. The frameworks exist. Most teams just can't tell when to use which one.

Visit Moltin

The Problem With Single-Shot Thinking

Your typical AI agent takes a prompt, generates a response, and calls it a day. For simple tasks, that's fine. Ask it to summarize an email and you'll get something workable. Ask it to coordinate a project across three departments with conflicting priorities and you'll get creative fiction masquerading as a plan.

Single-shot agents can't maintain state across decisions. They can't backtrack when they realize they've gone down a dead end. They certainly can't explore multiple solution paths and pick the best one. They're fundamentally reactive systems dressed up as intelligent assistants.

This is the dirty secret of most "AI automation" platforms. They're running glorified if-then statements with an LLM wedged in. When conditions get complex, they break. When edge cases appear, they hallucinate. When mistakes compound, they keep going because they have no way to recognize they're off track.

When Linear Thinking Works

Chain-of-Thought prompting was the first serious attempt to make LLMs show their work. Instead of jumping straight to an answer, the model generates intermediate reasoning steps. Think of it as forcing the agent to talk through its logic before committing.

The original research from Jason Wei and colleagues at Google Research showed impressive results. On the GSM8K (Grade School Math 8K) math benchmark, a 540-billion parameter model using Chain-of-Thought achieved state-of-the-art accuracy, surpassing even fine-tuned GPT-3 with a verifier. That's not a small improvement. That's a complete shift in capability.

But here's what the benchmarks won't tell you: Chain-of-Thought only really kicks in at scale. Models with fewer than 100 billion parameters produced reasoning chains that seemed coherent but were actually wrong, leading to worse performance than standard prompting. If you're running smaller models, adding Chain-of-Thought might actually hurt you.

And there's another catch that teams discover too late. Recent research from Wharton's Generative AI Labs tested Chain-of-Thought prompting on modern reasoning models and found minimal benefits. For models like o3-mini and o4-mini, the average improvements were only 2.9% and 3.1% respectively. These models already reason step-by-step internally. Asking them to do it explicitly is like asking a marathon runner to count their steps.

When to Use Chain-of-Thought

Use Chain-of-Thought when your task needs transparent reasoning but follows a mostly linear path. It works for math problems, logical deduction, and cases where you need to audit the agent's thinking. Multi-step calculations. Sequential analysis. Anything where B genuinely follows A.

Don't use it for tasks where the path branches, where backtracking matters, or where you're running bleeding-edge reasoning models that already do this work behind the scenes. And definitely don't use it just because someone told you it's "best practice." The Wharton study found that for many modern models, the gains must be weighed against increased response times and potential decreases in perfect accuracy due to more variability.

One more thing: Chain-of-Thought burns tokens. You're asking the model to generate all that intermediate reasoning, and you're paying for every word. If you're running thousands of queries a day, the cost difference between a terse answer and a Chain-of-Thought response adds up fast.

When Agents Need to Touch the World

Chain-of-Thought keeps everything in the model's head. ReAct, short for "Reasoning and Acting," lets the agent actually do something about its reasoning. It alternates between thinking and taking actions, using external tools to gather information or execute tasks.

The ReAct framework from Shunyu Yao and colleagues at Princeton and Google Research showed that on interactive decision-making benchmarks, ReAct outperforms imitation and reinforcement learning methods by an absolute success rate of 34% and 10% respectively.

Here's how it works in practice. The agent encounters a question it can't answer from knowledge alone. It reasons about what information it needs. It calls a tool to get that information. It incorporates the results into its reasoning. It repeats until it has an answer.

This is huge for production systems because most real work involves touching external systems. You can't schedule a meeting by reasoning about calendars. You can't generate a financial report without pulling actual data. You can't debug code without running it. ReAct gives agents the ability to interact with the world while maintaining a reasoning trace you can actually follow.

ReAct in Production

The catch with ReAct is that it requires infrastructure. You need tools the agent can call. You need a way to handle failures when those tools return garbage. You need guardrails so the agent doesn’t go off on a forty-step tangent when two steps would suffice.

But when you get it right, ReAct is transformative. I’ve seen customer service agents that can look up order history, check inventory, and process refunds without human intervention. Data analysis agents that can query databases, run statistical tests, and generate visualizations. DevOps agents that can read logs, identify issues, and even apply fixes.

The key is understanding that ReAct isn’t just about tool use. It’s about maintaining context across actions. Each step informs the next. The agent isn’t just executing a script. It’s adapting based on what it learns.

One warning: without proper constraints, ReAct agents can spiral. They’ll make a tool call, get a result that suggests another tool call, then another, until you’re fifteen steps deep and have no idea how you got there. You need mechanisms to detect loops and dead ends. You need a way to force the agent to commit to an answer instead of searching forever.

When You Need to Explore

Most problems don’t have one obvious solution path. They have multiple approaches, each with different trade-offs. Chain-of-Thought picks one path and commits. Tree-of-Thoughts evaluates several paths before deciding.

The Tree-of-Thoughts framework from Shunyu Yao and colleagues at Princeton and Google DeepMind showed dramatic improvements over traditional approaches. In the Game of 24 task, while GPT-4 with Chain-of-Thought prompting only solved 4% of tasks, Tree-of-Thoughts achieved a success rate of 74%. That’s not a marginal gain. That’s the difference between unusable and production-ready.

Tree-of-Thoughts works by maintaining multiple reasoning paths simultaneously. The agent generates several potential next steps, evaluates them, picks the most promising ones, and continues from there. If a path hits a dead end, the agent backtracks and tries another branch.

This is computationally expensive. You’re essentially asking the model to explore a search space, and search spaces grow exponentially. But for problems where the initial decision matters, where wrong turns are costly, and where you need to find good solutions rather than just acceptable ones, the cost pays off.

When Tree-of-Thoughts Makes Sense

Use Tree-of-Thoughts for problems that require strategic lookahead. Planning complex workflows. Optimizing resource allocation. Anything where you need to consider multiple options before committing.

Don’t use it for simple queries or real-time systems. The computational overhead kills you. A customer asking for their order status doesn’t need the agent to explore five different ways to look it up. They need an answer now.

Tree-of-Thoughts is also harder to implement than Chain-of-Thought or ReAct. You need search algorithms. You need evaluation functions that can judge partial solutions. You need infrastructure to manage and prune branches. Most teams aren’t ready for this level of complexity unless they’re solving problems where the alternative is manual planning by expensive humans.

Picking Your Architecture

The real question isn’t which framework is best. It’s which architecture matches your problem.

Reactive agents map inputs directly to outputs. They’re fast, predictable, and work great for well-defined tasks. Think chatbots handling common questions, or systems routing tickets to the right department. The environment is stable. The rules are clear. You don’t need planning, just quick responses.

Planning agents build internal models and think multiple steps ahead. They’re essential when decisions have long-term consequences, when the environment is complex, or when you need to coordinate multiple actions. Think autonomous systems managing warehouse operations or agents planning marketing campaigns across channels.

Hybrid agents layer both approaches. Fast reactive responses for common cases. Deeper planning for complex scenarios. This is what most production systems actually need, but it’s also the hardest to build right. You need clear rules for when to react and when to think. You need coordination mechanisms so the layers don’t fight each other.

Gartner predicts that by 2027, more than 40% of agentic AI projects will be canceled as projects fail, costs spike, business value stays fuzzy, and risk controls lag. That’s not because the technology doesn’t work. It’s because teams pick architectures that don’t match their problems.

The Decision Matrix

Start simple. If your task can be solved reactively, don’t add planning overhead. A reactive agent that works beats a planning agent that’s still in development.

Add Chain-of-Thought when you need transparency and the task follows a mostly linear path. You want to see the agent’s reasoning. You need to validate each step. The extra tokens are worth the auditability.

Bring in ReAct when your agent needs to interact with external systems. If the answer depends on real-time data or if the agent needs to execute actions, you need tool use. Don’t try to fake this with prompt engineering.

Consider Tree-of-Thoughts only when wrong decisions are expensive and you have the computational budget to explore alternatives. This is not your starting point. This is where you go when simpler approaches have hit their limits.

Build hybrid architectures when you need both speed and depth. Customer service that handles simple queries instantly but escalates complex issues to deeper reasoning. DevOps agents that react to alerts but plan remediation strategies. The coordination overhead is real, but so is the value of getting both capabilities.

What Actually Ships

The agents that make it to production have a few things in common. They start simple and add complexity only when necessary. They have clear boundaries around what they can and can’t do. They fail gracefully instead of hallucinating their way through uncertainty.

They also have humans in the loop at key decision points. Not because the AI can’t handle it, but because production systems need mechanisms to catch mistakes before they compound. The best agent architectures make it easy for humans to review, override, and learn from edge cases.

Most importantly, shipping agents have measurable success criteria. Not vague notions of “helpfulness.” Concrete metrics tied to business outcomes. Percentage of tickets resolved without escalation. Reduction in manual data entry hours. Increase in workflow completion rate.

If you can’t measure it, you can’t improve it. If you can’t improve it, it won’t ship.

Choose your architecture based on the problem you’re solving, not the paper you read last week. Start with the simplest thing that could work. Add complexity when simpler approaches fail and you understand why. Test against real workflows, not toy examples.

And remember: the point isn’t to build impressive AI. It’s to build AI that actually does the job.

I was reading a recent Substack Post titled "The AI revolution is here. Will the economy survive the transition?"

If you're not familiar with it, some influential names in AI jumped into a Google doc to debate certain topics involving AI. The authors included:

• Michael Burry, the guy who called the 2008 crash.

• Jack Clark, co-founder of Anthropic.

• Dwarkesh Patel, who's interviewed everyone from Mark Zuckerberg to Tyler Cowen.

• Patrick McKenzie, the moderator.

As I was reading through it, one of their exchanges brought me to a pause.

Jack Clark said something regarding discussions with policymakers that applies just as much to the enterprise:

"This is the worst it will ever be! and it's really hard to convey to them just how important that ends up being."

Read that again and think about it. The AI capabilities causing disruption today are the weakest they will ever be. Every concern you have about AI right now?

It's going to get worse…or better, depending on whether you're ready.

Visit Moltin

The Obvious

When Clark tells policymakers this is the worst it’ll ever be, he’s making a point about trajectory that most people miss. If you last played with LLMs in November, you’re now wildly mis-calibrated about the frontier.

Think about what that means for your business. Whatever AI can do today represents the floor.

Not the ceiling. The floor.

Is your competitor experimenting with AI-powered customer service? If so, then that chatbot is the least sophisticated their AI strategy will ever be. Those coding assistants that seem merely helpful? They'll only get more capable. Fast.

The question isn't whether AI will transform your industry. It's whether you'll lead that transformation or be in a position requiring you to catch up.

Strategic Implications

Most executives are trained to plan based on current market conditions with reasonable projections for gradual change. But AI doesn't follow gradual improvement curves. It accelerates.

The competitive window is shrinking

That "wait and see" approach to AI adoption isn't cautious. It's falling behind in real-time. Every quarter you delay, your competitors aren't just moving ahead. They're moving ahead faster because the tools themselves are improving.

According to a 2024 McKinsey survey, organizations that adopted AI early were 2.3 times more likely to report significant revenue increases attributed to AI than late adopters.

But here's the part that should keep you up at night. The gap between early and late adopters widened by 40% compared to the previous year's survey. The distance between leaders and laggards isn't staying constant. It's growing.

Every quarter you delay, your competitors aren't just moving ahead. They're moving ahead faster because the tools themselves are improving. It's compounding in ways most people don't grasp yet.

Infrastructure choices compound

The data strategies, cloud architectures, and integration frameworks you build now will either enable or constrain your ability to leverage increasingly powerful AI systems. Building for today's capabilities means rebuilding constantly. Building for adaptability means staying ahead.

Here's an example. If you're building data pipelines that assume current AI models can only process structured data, you're already behind.

The latest models handle video, audio, images, PDFs, and unstructured text with equal ease. Your infrastructure choices made in 2026 based on 2025 capabilities are already outdated.

How much of your current software stack is hardcoded to work with specific tools, versions, or even, specific platform versioned/API versioned data schema? Now imagine you need to upgrade your AI capabilities every six months. Systems that take nine months (let alone years) to integrate new capabilities will leave you perpetually behind.

Talent needs are shifting underneath you

The skills your organization needs today are different from what you'll need in six months. The same adage can be applied here as well. If you're hiring for today's AI landscape, you're already hiring for yesterday's needs.

The World Economic Forum's 2025 Future of Jobs Report found that 39% of workers' core skills are expected to change by 2030.

Not just be assisted with. Change.

And that's down slightly from 44% predicted in their 2023 report, not because disruption is slowing but because companies are finally investing more in training to keep pace.

Think about it differently. You can hire the world's best prompt engineer today. In a year, that skill might be as relevant as being an expert at operating a fax machine because promptless-focused workflow engines exist today.

The winning move isn't hiring for specific AI skills. It's building teams that can learn and adapt faster than the technology evolves. See my article titled The Rise of the Forward Deployed Engineer for a great example of a new position designed for adaptability.

Why We Get This Wrong

There are understandable reasons why leadership teams underestimate AI's trajectory. Let's be honest about them.

Pattern matching to the wrong examples

We've seen hype cycles before. Blockchain. VR. 3D printing. Many found niche applications but didn't transform entire industries overnight.

The temptation is to pattern-match AI to these examples. Don’t worry, it’s natural. But AI is fundamentally different. It's a general-purpose technology more like electricity or the internet than any specific application.

Electricity didn't just create electric lighting. It transformed manufacturing, communication, transportation, and entertainment. AI is following the same path, just faster.

Goldman Sachs Research forecasts that AI could boost U.S. labor productivity by 15% over 10 years, with the technology's impact on global GDP potentially reaching 7% (about $7 trillion) or even climbing to 10-15% in their more recent projections.

For context, $7 trillion is roughly the entire annual GDP of France and the UK combined.

We're not talking about a niche technology finding its market. According to their January 2026 analysis, AI-related spending already accounted for almost one percentage point of U.S. real GDP growth in the first half of 2025 alone.

Exponential change breaks our brains

Our brains are wired for linear thinking. When you see an AI system that's 70% as good as a human at a task, it's natural to think "we have time."

But the jump from 70% to 90% might happen in months. Not years. And 90% to 95% might be enough to fundamentally change human-to-human workflows.

By early 2026, we're seeing Claude Opus 4.5 break 80% on SWE-bench Verified (real GitHub bug fixes), Gemini 3 Pro hit 92.6% on GPQA Diamond (PhD-level science questions), and GPT-5.2 lead on GDPval (real-world professional work across 44 occupations).

The pace hasn't slowed. It's accelerated.

The difference between "interesting toy" and "replaces entire job categories" can be as small as a 15% improvement in capability. You're not watching a gradual evolution. You're watching phase transitions.

Recency bias is hurting you

You evaluate AI based on what it can do today. Maybe you tried ChatGPT for a few tasks or saw a demo. But the version you tested is already outdated by the time you formed an opinion about it.

Imagine you're an executive at a Fortune 500 company that dismissed AI in 2025 after testing it on tasks where it performed poorly. The decision seemed justified at the time. The models were clunky, error-prone, not ready for prime time.

It’s January of 2026 and you are ready to engage once again. You don’t realize it but you gifted your competitors a leg up in their last 4 quarterly earnings announcements. Your competition had nearly 12 months of organizational learning.

How?

On the technology side, custom integrations were built. Workflow optimizations were developed out. Training cycles were completed. Examples were captured and created. Agents began learning about their respective domains.

What’s even worse, is that your competitors had learned how to use it effectively at a lower capacity while your organization sat still. What did your competitors accomplish?

Lets examine this:

• Custom integrations built and built to scale - check.

• System of Records (SOR) vendor relationships/capabilities examined and contracts reviewed - check.

• Human-to-human workflow analysis, alignment, and optimization completed - check.

• FDE’s (Forward Deployed Engineers) up-skilled within the organization - check.

All of this accomplished despite the fact that the agents quality rate was at 20%.

Some of this might sound extreme. Maybe even alarming, but the landscape is changing faster than most can grasp. The reason? We've spent decades building enterprise systems around deterministic logic. If X happens, then do Y every time.

Predictable.

AI doesn't work that way. It's probabilistic, contextual, sometimes brilliant and sometimes wrong in ways your existing systems were never designed to handle. You won't fully grasp how transformational this is until you pilot it, capture the context of how you operate and train the agents.

By then, your competitors will have spent 18 months learning to work with and negotiate that uncertainty and risk.

Uncomfortable Economics

Michael Burry, the guy who predicted the 2008 crash and, later, had a movie made about him, participated in this conversation as well. I’d like to take some time to examine his skepticism.

Burry pointed out that in past technology cycles, when one company made a major investment like adding an escalator, competitors had to follow. In the end, neither benefited from that expensive project. No durable margin improvement. Both companies ended up in the same spot.

He worries that's how most AI implementations will play out. Trillions in spending with no clear path to utilization by the real economy. Most companies won't benefit because their competitors will benefit to the same extent. Neither will have a competitive advantage.

The answer: Your company's system of context (more about this in an upcoming article).

When AI commoditizes intelligence itself, the companies that win won't be the ones with the best models or agents. They'll be the ones with the richest, most interconnected understanding of their business, customers, and operations.

Your proprietary data. Your institutional knowledge. Your customer relationships and feedback loops. Your documented processes and hard-won lessons.

This is why companies that wait are making a worse bet than Burry realizes. You're not just missing out on productivity gains. You're missing the window to build your context graph while your competitors are building theirs.

Every month of customer interactions, every workflow optimization, every integration, every piece of feedback creates context that makes your AI more valuable than a competitor's AI using the same underlying model.

What This Means For Your Strategy

Understanding that this is the worst it'll ever be should reshape how you think about AI strategy. Not next quarter. Now.

Build for adaptability, not today’s capabilities

Don't ask "what can AI do for us right now?"

Ask "how do we build an organization that can rapidly integrate increasingly powerful AI capabilities?"

This means creating modular systems that can swap in better AI models as they become available. Establishing data pipelines and governance frameworks that will scale with the rapid rate of capability creation. Building teams that can experiment, learn, and pivot quickly.

The winning approach is building abstraction layers. Don't build directly on top of one AI model. Build systems that can plug in whatever the best available model is at any given time.

Yes, this requires more upfront architectural thinking. It's worth it.

Accelerate your learning curve beyond recognition

Your organization's AI literacy is a depreciating asset if you're not actively developing it. What seemed cutting-edge six months ago is table stakes today.

The executives who'll thrive aren't necessarily the ones who understand AI deeply right now. They're the ones who are learning the fastest (a mentor of mine has taught me that — thank you Rashmi).

I've been part of companies that create AI councils that meet quarterly to discuss strategy. By the time they make a decision, the landscape has shifted. On the other hand, I have been part of companies who have empowered small teams to experiment daily, fail fast, and share learnings across the organization.

A 2024 study by Boston Consulting Group found that companies with decentralized AI experimentation programs saw 3x faster adoption rates than those with centralized, committee-driven approaches.

Speed of learning beats depth of planning when the environment changes this fast.

Every executive should be using AI tools daily for real work. Not playing with them. Using them. You can't make informed strategic decisions about technology you don't understand at a visceral level.

Your VP of Strategy should be using AI to analyze competitive threats. Your CFO should be using it to spot patterns in financial data. Your CHRO should be using it to identify retention risks.

Rethink what creates defensible value

If your competitive advantage relies on tasks that AI is even marginally good at today, that advantage is eroding. Fast.

The defensible moats in an AI-enabled world look different. Proprietary data that gets better with use still matters. Deeply integrated customer relationships still matter. Brand trust and regulatory positioning still matter. Speed of adaptation and organizational learning matters more than ever.

But here's what doesn't create a moat anymore: having smart people who can do analysis faster than average. AI is already better than “average” at most analytical tasks. It'll be better than “good” by the next model upgrade announcement this quarter.

The pyramid is flattening.

Plan for workforce transformation

Many executives think about AI as an augmentation tool. Something that makes existing workers more productive. That’s not wrong, but it’s incomplete.

As capabilities improve, entire job categories will transform. The question isn’t just “how do we make our analysts 20% more efficient?” It’s “what does the analyst role become when AI can do 80% of traditional analyst work?”

According to research from the University of Pennsylvania and OpenAI, around 80% of the U.S. workforce could have at least 10% of their work tasks affected by AI. Approximately 19% of workers may see at least 50% of their tasks impacted. This research was published in 2023 based on capabilities that already existed then.

The capabilities have improved dramatically since. The impact percentages have gone up.

Here’s what smart companies are doing. They’re not just thinking about productivity gains. They’re thinking about role transformation. What happens when your customer service team spends 80% less time answering routine questions? Do you cut headcount? Or do you redeploy those people to higher-value work that AI can’t do yet?

The companies that treat this as a cost-cutting exercise only will see short-term gains and long-term strategic weakness. The companies that treat it as a transformation opportunity will build entirely new capabilities.

This is the worst AI will ever be. Proceed accordingly.

AI agents are only as capable as the tools they can use.

In Moltin, your workflows don't operate in a vacuum. They need to pull data from your CRM, search the web for current information, analyze files your team uploaded, or connect to your company's internal APIs. That's where Skill Tools come in.

This feature turns your AI agents from isolated processors into connected systems that can interact with the rest of your tech stack. Admins can browse a catalog of pre-built integrations, install third-party tools with a few clicks, or build custom connections to proprietary APIs using OpenAPI specifications.

Once a tool is installed in your workspace, every workflow can use it. No redundant setup across multiple workflows. No reinventing the wheel every time you need to query Salesforce or send a Slack message. Install it once, use it everywhere.

Visit Moltin

Editor Tools

When in the Editor, the Tools screen is where you manage every integration available to your workflows. Think of it as your workspace's toolbox. Every tool you've installed lives here in a single list.

Benefits

Having a centralized view of installed tools solves a problem that plagues most automation platforms: tool sprawl. Without a dedicated management screen, you'd have no idea which integrations are already set up, which workflows are using them, or whether you're about to install a duplicate. The Tools screen prevents that chaos.

When you open the Tools screen from the Workflow Editor's top navigation menu, you see exactly what your agents can access. This matters when you're building new workflows. Instead of wondering whether the Stripe integration is already configured, you can check the Tools screen in seconds. If it's there, you're good to go. If it's not, you know you need to install it.

This centralized approach also simplifies maintenance. When an API key expires or authentication credentials need updating, you know exactly where to go. Update it once on the Tools screen, and every workflow using that tool picks up the change. No hunting through dozens of individual workflow configurations to update the same credential fifty times.

How to Access the Tools Screen

Open any skill in the Skill Editor. You'll see the canvas where you build and design your agent’s skills. At the top of the canvas sits a navigation menu. Click the link labeled Tools. The Tools screen appears, showing a list of every tool you've already installed.

This list displays each tool's name and key details. You can scan it quickly to see what's available. If you've got nothing installed yet, the list will be empty. That's fine. You're about to change that.

Adding Pre-Built Tools

Pre-built tools are ready-made integrations for popular services. Moltin's catalog includes hundreds of options covering everything from communication platforms to finance systems.

Benefits

Pre-built tools save you from writing custom integration code. Someone already did the work of mapping API endpoints, handling authentication flows, and documenting available actions. You just install it and start using it.

The catalog organizes tools into categories: Communications, Finance, Human Resources, IT & Engineering, Logistics, Operations, Productivity, Safety & Compliance, Sales, Transportation, Weather, and more.

If you're looking for a specific type of tool, filtering by category narrows your options fast. Need a CRM integration? Check Sales. Looking for a chat platform? Hit Communications. There's also an All Apps view if you want to browse everything, and a Custom Apps category for tools you've built yourself.

Each pre-built tool comes with detailed information about what it can do. Before you install anything, you can review supported authentication methods, check the version number, see when it was last updated, and browse the total number of actions (API endpoints) available.

There's also a link to external documentation if you need to verify specific capabilities. This transparency means you're never installing a tool blind. You know exactly what you're getting.

How to Add a Pre-Built Tool

From the Tools screen, click the Add Tool button in the top right corner. The tools catalog opens in a modal window. You've got two ways to find what you need: filter by category or search directly.

If you know the tool's name, type it into the search box. The catalog filters results in real time. If you're exploring options, click on a category filter. Only tools in that category appear. Browse until you find the tool you want.

When you spot your tool, click the green Add Tool button next to it. This opens the tool's details panel. Here's where you verify everything before committing.

Check the supported authentication method type to make sure it matches what you've got access to. Review the version and last updated date to confirm it's current. Scan the total actions available to see how many API endpoints the tool exposes.

If you need proof that a specific endpoint exists, scroll down to the actions listing. Every available endpoint is listed there.

The panel also includes an About section describing what the tool does and an external documentation link if you want to dig deeper. Once you're confident this tool does what you need, click the orange Add Tool button at the bottom of the panel.

The Add Tool panel appears next, asking you to choose your authentication type. The options match what the tool supports: Basic Auth, OAuth2, API Key, Bearer Token, or No Auth. Select the one that fits your setup.

Each authentication type requires different fields. For Basic Auth, you’ll enter the API URL, username, and password. For OAuth2, you’ll need the grant type, access token URL, token name, API URL, client ID, client secret, scope, and a few additional options like whether to use authentication headers, plus audience, resource, and header prefix.

If you select Password as the grant type (for ROPC credentials), you’ll also provide a username and password. API Key authentication asks for the API URL, the API key itself, and the API key name. Bearer Token requires just the API URL and the token. No Auth doesn’t ask for anything because, well, there’s no authentication to configure.

Fill out the required fields for your chosen authentication type. Once everything’s entered, click the orange Install Tool button at the bottom of the panel. The tool installs immediately and appears in your Tools screen list.

Every workflow in your workspace can now use it.

Creating Custom API Tools

Pre-built tools cover the popular services, but your company probably runs on some proprietary systems too. Custom API Tools let you connect to any API by uploading an OpenAPI specification file.

Benefits

Custom tools are your escape hatch from vendor lock-in. If your company built an internal inventory system, a custom billing platform, or a homegrown analytics dashboard, you can integrate it into Moltin without waiting for someone to build a pre-made connector. As long as you've got an OpenAPI spec file, you can make it work.

This flexibility extends to niche third-party services too. Not every SaaS tool gets the pre-built integration treatment. If you're using a specialized compliance platform or a regional payment processor that isn't in Moltin's catalog, build a custom tool. The process takes minutes if you've got the spec file ready.

Custom tools also give you control over how the integration is configured. You define the app name, choose the authentication type, set the API base URL, and provide a documentation URL.

Once created, the custom tool behaves exactly like a pre-built one. It shows up in your Tools screen, becomes available to all skills, and can be managed or deleted just like any other tool.

How to Create a Custom API Tool

From the Tools screen, click Add Tool. When the catalog modal opens, you'll see a button labeled Create Custom Tool. Click it.

The Create Custom API Tool panel slides open. This is where you'll upload your OpenAPI specification file and configure the tool's settings. The file must be in YAML or JSON format with a .yml, .yaml, or .json extension.

If you don't have a spec file handy or need to see what one looks like, Moltin provides two sample templates. Click Download Sample YAML File or Download Sample JSON File to grab a template you can modify.

Once you've got your spec file ready, upload it to the panel. Then fill out the required fields. App Name is whatever you want to call this tool. Make it descriptive so you'll recognize it later in the Tools screen. Auth Type gives you the same options as pre-built tools: Basic Auth, OAuth2, API Key, Bearer Token, or No Auth. Pick the one your API uses.

API Base URL is the root URL for your API. This is usually something like https://api.yourcompany.com. Documentation URL is optional but helpful. If your API has public or internal documentation, link it here so other admins know where to find details about endpoints and parameters.

After filling out these fields, submit the form. Moltin processes your OpenAPI spec file and creates the custom tool. It appears in your Tools screen alongside pre-built tools. Any workflow in your workspace can now access it.

Managing Installed Tools

Tools don’t just sit in your workspace forever unchanged. Authentication credentials expire. APIs get deprecated. Sometimes you realize a tool isn’t needed anymore and you’d rather clean up the clutter.

Benefits

Being able to delete tools matters more than it sounds. Over time, workspaces accumulate integrations that no longer serve a purpose. Maybe you switched CRM platforms and the old integration is just sitting there. Maybe a tool was installed for a single experimental workflow that never made it to production. Deleting unused tools keeps your Tools screen manageable and reduces the chance of confusion when building new workflows.

The deletion process is straightforward, but Moltin doesn’t let you shoot yourself in the foot without warning. If you delete a tool that’s currently being used by active workflows, those workflows will error out when they try to execute. That’s expected behavior, but Moltin notifies you when it happens so you’re not left wondering why a workflow suddenly broke. This notification system means you can delete tools with confidence, knowing you’ll be alerted if something goes wrong.

How to Delete a Tool

From the Tools screen, locate the tool you want to remove. Click on it to open the tool’s details. Somewhere in that panel (the exact placement varies, but it’s usually near the top or bottom) you’ll find a delete or remove option. Click it.

Moltin will likely ask you to confirm the deletion. This is your last chance to back out. If you’re sure, confirm. The tool disappears from your Tools screen immediately. If any workflows were using that tool, they’ll fail the next time they run and you’ll receive a notification explaining what happened. At that point, you can either reinstall the tool or modify the affected workflows to use a different integration.

Install Once, Use Everywhere

Most automation platforms make you configure integrations separately for each workflow. That’s tedious and error-prone. Moltin takes a different approach. Install a tool once in your workspace and it becomes available to every workflow.

Build a new workflow that needs to query your database? The database tool is already there. Create a customer support workflow that needs to send Slack notifications? Slack’s already installed.

This workspace-level approach scales better as your automation needs grow. With five workflows, the difference between per-workflow configuration and workspace-level installation is annoying but manageable. With fifty workflows, it’s the difference between a maintainable system and an unmaintainable mess. When that API key needs updating, you change it in one place instead of fifty.

The Tools screen, the catalog, and the custom tool builder all serve this philosophy. Make it easy to install. Make it easy to browse what’s available. Make it easy to connect proprietary systems. Then get out of the way and let your agents do their work.

Visit Moltin

The numbers don't lie, but they do hurt.

According to S&P Global Market Intelligence's 2025 survey of over 1,000 enterprises across North America and Europe, 42% of companies abandoned most of their AI initiatives before they reached production. That's up from just 17% the previous year. The average organization scrapped 46% of AI proof-of-concepts before they ever saw daylight.

RAND Corporation's analysis puts it even more bluntly: over 80% of AI projects fail, double the failure rate of non-AI technology projects.

The pattern repeats itself everywhere. MIT's research found that 95% of generative AI pilots at companies are failing to deliver meaningful revenue impact. IDC reports that 88% of AI proof-of-concepts never transition into production. These aren't rounding errors. They're a systemic breakdown in how enterprise AI gets implemented.

Here's what's strange: the technology works. The models are getting better every quarter. The platforms are maturing. Yet companies keep getting stuck in what I call pilot hell, a purgatory where promising demos turn into abandoned Slack channels and awkward quarterly business reviews where nobody wants to talk about "that AI thing we tried last year."

The winners, though, are doing something fundamentally different. They're not sending better slide decks or running longer discovery calls. They're embedding engineers directly inside business-facing organizations. Not consultants who architect and disappear. Not sales engineers who demo and hand off. Real builders who move in, build agents, untangle data disasters, navigate political minefields, and don't leave until the agent actually works.

This is the Forward Deployed Engineer. And it's becoming the critical capability that separates enterprises that actually deploy AI at scale from those stuck running perpetual pilots.

Visit Moltin

Why Traditional Implementation Dies on Contact

The old model worked fine when you were buying software that lived in a box. Purchase the licenses. Send your team to a training session. Maybe bring in a consultant for a few weeks. Hand it off to IT and move on to the next project.

AI breaks that model completely.

First, there's the data problem. Every demo runs on clean, normalized, beautifully labeled data that somebody spent three months preparing.

Enterprise data is a dumpster fire.

It doesn’t matter how many naming convention conversations you have been through. There are always fields that should be timestamps and are stored as strings. Product SKUs or reference numbers that should match across systems but don't.

Critical information lives in PDFs, Excel macros, and somebody's brain who retired last Spring.

You can't fix this from a conference room in your headquarters. You need someone on-site who can look at the actual databases, talk to the actual humans who use them, and build the actual pipelines to make them usable.

Second, there's the integration conundrum.

Your AI platform needs to talk to your CRM, which was customized by a vendor that went bankrupt in 2018. It needs to pull from your data warehouse, which runs on a version of Snowflake from 2019 that nobody's allowed to upgrade because it might break finance reporting. It needs to trigger workflows in Salesforce, where half the fields are named things like "Custom_Field_237" and nobody remembers what they do.

This isn't a technical specification problem. It's archaeology.

Third, and this kills more projects than anything else, there's organizational resistance.

The people whose jobs might change don't trust the AI. The IT team doesn't trust the vendor's security model. The compliance team doesn't trust how the platform handles data. The VP who sponsored the pilot just left for another company.

You're not going to overcome this with a better PowerPoint. You need someone who can sit in their meetings, understand their concerns, build trust over weeks and months, and prove value one workflow at a time.

Remote implementation teams can't do this. They aren’t part of the hallway conversations where someone mentions that "the sales team will never use this because it doesn't integrate with the tool they actually use."

They're not in the 4 PM emergency meeting when the head of a department suddenly needs to see how the AI will affect headcount planning. They're not around when the intern mentions that all the good data is actually in a different system that nobody told you about.

What Makes FDEs Different From Everyone Else

Sales engineers show up for the demo. They're good at it. They know the platform inside and out and can make it dance. But once the contract is signed or the project is green lit, they're gone. Their incentive is to sell a vision and close deals, not to make implementations succeed.

Contractors show up for the project. They write requirements documents and system architecture diagrams. They might even build something. But they’re billing by the hour, and their incentive is to extend the engagement, not to transfer knowledge and get out.

If they do decide to build something, they're usually stitching together legacy systems and patchwork integrations to create a custom solution that technically works but becomes a maintenance nightmare. When they leave, you've got something fragile that nobody internal understands how to fix when it breaks.

Which leads me to IT.

Your internal IT team is stretched thin. They’re managing existing systems, handling security patches, dealing with infrastructure issues, and trying to keep the lights on.

They don’t have bandwidth to become experts in a new AI platform while also maintaining everything else. They want to help, but they’re juggling ten other priorities that all feel equally urgent.

Your business analysts understand the processes that need automation, but they can’t write the code to make it happen. They can document requirements and validate outputs, but they’re stuck waiting for someone technical to build the actual implementation. The gap between “here’s what we need” and “here’s working software” never closes.

FDEs are something else entirely. They combine the technical depth of a product engineer with the customer empathy of a consultant and the urgency of a sales engineer whose commission depends on the customer going live.

They're embedded long enough to understand the actual problem, not the one described in the RFP. They can build production agents and workflows, but they're also willing to spend a Tuesday afternoon sitting with the operations team to understand why they don't trust the AI's recommendations.

Palantir pioneered this model in the early 2010s when they realized that enterprise customers, especially governments and massive corporations, didn't need more features. They needed engineers who could make the features work inside fragmented data systems, legacy workflows, and high-stakes operational constraints.

So Palantir embedded engineers, called “Deltas” back then, directly inside customer teams. Not as consultants, but as builders who could write code, untangle data pipelines, adapt workflows, and uncover constraints that no discovery call ever reveals.

The role looks like a startup CTO job.

You work in small teams and own end-to-end execution of high-stakes projects. One day you’re building workflows at scale. The next day you’re in a conference room explaining to a skeptical operations manager why the AI won’t accidentally order 10,000 extra widgets. The day after that you’re debugging why the data pipeline failed at 3 AM.

Here's the key difference: FDEs improve the product.

Traditional consultants build around the product. FDEs see what's actually broken in the field and feed that back to product teams. They build custom extensions when necessary, but they're building on the platform, making it better for the next team who is scheduled to participate in a project kick-off meeting next week.

The Dirty Work Nobody Talks About

Let's get specific about what FDEs actually do when they're embedded inside a business organization. This is the work that doesn't make it into the case studies.

They fix the data.

Not "data engineering" in the abstract sense. They're in the database at 7 AM because the batch process failed overnight and the business unit’s daily dashboard is blank.

They're writing Python scripts to backfill missing records because somebody's Excel export dropped 3,000 rows and nobody noticed for six months.

They're building validation rules to catch when a product code gets entered as "N/A" instead of null because that's how the legacy system handles missing values.

They navigate the politics.

The VP of Sales wants the AI to prioritize leads differently than the VP of Marketing. The engineering team is terrified the AI will make them look bad if it suggests technical solutions they didn't think of. The legal and security teams needs proof that the AI won't expose customer PII before they'll sign off on anything.

The FDE becomes a translator, a mediator, and occasionally a diplomat. They learn when to push and when to wait. They figure out who the real decision-maker is, which is never the person with "decision-maker" in their title.

They build trust through reliability.

When something breaks, and something always breaks, the FDE is the person who picks up the phone. They're the one who says "I'll figure it out" and then actually does. They build credibility not through presentations but through showing up every time things go sideways.

This work is exhausting. It's why FDE roles have high turnover at companies that don't support them properly.

You're context-switching constantly between deep technical work, business team hand-holding, internal escalations, and putting out fires. You're working too much. You're on calls across time zones. You're personally responsible for whether a multi-million-dollar project turns into a case study or a cautionary tale.

But it's also why FDEs become the most valuable people in an AI-fluent company. They know what actually matters to the business teams. They know which features are table stakes and which ones are marketing fluff. They know where the product is strong and where it's held together with duct tape. They're the bridge between "this works in our demo environment" and "this works in production handling real business problems."

The Economics of Embedding Engineers

Let me address the obvious objection: this is expensive.

FDEs earn top-tier salaries because they need software engineering skills plus business-facing abilities plus domain expertise plus the willingness to operate out of all of the office types your enterprise may provide, including “field offices”.

According to recent market research, FDEs in the US earn between $180,000 and $300,000 depending on seniority, company, and where they live. In Europe, enterprise-grade FDE contractors often bill £600-£700 per day.

Companies need to hire selectively because the role demands creativity, judgment, and business-facing charisma on top of technical ability. You can't just hire smart engineers and throw them at business leaders. Many brilliant engineers have zero interest in the business-facing parts of the job. Many great business-facing people can't debug a data pipeline at scale.

So why would a company, let alone an IT department, invest this much in a services-heavy model when they're trying to build a scalable agentic workforce? Because the alternative is worse.

A single failed AI implementation can waste $200,000 to $1 million in sunk costs, not counting the opportunity cost of delayed automation.

When projects fail, it's rarely because the vendor's product was fundamentally broken. It's because implementation hit a wall that internal teams couldn't get past.

Maybe the data integration was too complex for IT to handle alongside their existing workload. Maybe the business users never adopted it because nobody had time to properly train them. Maybe the project lost executive sponsorship because it took too long to show value.

An internal FDE prevents exactly these failures by owning the implementation end-to-end instead of hoping the vendor and your overstretched teams can coordinate effectively.

The math gets better when you realize FDEs don't just prevent churn. They accelerate time-to-value, which is how you expand successful use-cases. Instead of a six-month pilot that ends in "we need more time to evaluate," you've got production workflows running in eight weeks.

Instead of the business team using 10% of the platform's capabilities, they're using 60% because someone showed them how.

There’s also the competitive moat angle. Once you’ve embedded an FDE who’s built critical workflows on your platform, who’s integrated with all your systems, who’s earned trust across the organization, switching costs become a much larger concern.

It’s not just “replace the software.” It’s “replace the software and rebuild all the custom integrations and retrain everyone and lose the person who knows where all the bodies are buried.”

That’s why Palantir, at one point, had more forward-deployed engineers than traditional product engineers. They were building near-unchurnable accounts.

Who’s Winning With This Model

Palantir remains the archetype. They embedded engineers with governments, airlines, and banks to make Foundry and Gotham work in impossibly complex environments.

Their FDEs weren't there to sell, they were there to build production-ready workflows in close collaboration with the customer's teams. This model let Palantir solve problems faster, prove value earlier, and create adoption curves that competitors couldn't match.

OpenAI recently went all-in on forward deployed. Colin Jarvis, Head of Forward Deployed Engineering at OpenAI, initially joined as a Solutions Architect in 2022. By early 2025, he'd built a case for a dedicated FDE team.

That team has grown from two engineers to over ten. They work on the company's highest-stakes implementations, the ones where generic ChatGPT integration isn't enough and the customer needs bespoke workflows built on the OpenAI platform.

Salesforce deploys FDEs for its most complex AI implementations. When the deal is big and the environment unpredictable, they send engineers to ensure the outcome lands.

Stripe built a Revenue & Financial Automation FDE team to partner with strategic enterprise users and close product-market fit gaps that would otherwise derail deals.

The pattern is consistent. Enterprises that successfully deploy AI are building internal FDE capabilities because traditional implementation approaches can't handle the complexity.

You can't implement AI the way you implemented CRM software. The technology changes too fast. The integration points are too messy. The organizational resistance is too high. You need dedicated people who can build, teach, navigate politics, and stick around long enough to make it work.

It’s worth noting that smaller companies and startups often can’t afford the full FDE model. The costs are too high and the hiring bar is too difficult. But they’re adopting elements of it. They’re having engineers join customer calls instead of just account managers. They’re doing paid proofs-of-concept where they embed someone for a month to build the first workflow. They’re making implementation success a core part of the sales process, not an afterthought.

What This Means for Product Teams

First, product development needs to incorporate field feedback systematically. FDEs see what’s actually broken in a way that support tickets never capture. They know which features teams ask about in demos but never use in production. They know which limitations cause business teams to build workarounds.

You need a formal process for bringing those insights back into the roadmap. Otherwise, you’re just building features based on guesses about what the business teams need.

Second, you need to design for customization without creating technical debt. FDEs will extend your platform in ways you didn’t anticipate because every enterprise has unique requirements. If your platform isn’t architected to handle that gracefully, you end up with a mess.

You need APIs that are well-documented and in largely adopted specifications. You need extension points that are officially supported. You need ways for FDEs to build custom functionality that won’t break when you ship the next version.

Third, you have to hire differently. You’re not just hiring software engineers or data scientists. You’re hiring people who can thrive in ambiguous, business-facing, high-pressure situations.

They need technical depth, communication skills, a tolerance for grinding through problems and context-switching that would drive most engineers crazy. That’s a narrow hiring pool, and you need to pay competitively for it.

Fourth, you need to support FDEs properly or they’ll burn out and leave.

That means:

• Reasonable workloads provided by an ingestion pipeline via governance and prioritization.

• Career paths that don’t force them to become managers/directors if they want to advance. Think Enterprise-level Agentic Architects.

• Recognition that they’re doing work that’s just as valuable as product engineering even though it doesn’t show up on a project management dashboard somewhere.

What This Means for Those in the Market

If you’re evaluating AI platforms for your enterprise, the presence or absence of forward deployed capability should be a major factor in your decision.

Ask the vendor directly: do you embed engineers on-site for implementations? For how long? What’s their role versus our team’s role? How do they handle issues that come up after go-live?

If the answer is “we provide implementation guides and our support team is available via email,” that’s a red flag for complex deployments.

You’re going to hit problems that can’t be solved asynchronously. You’re going to need someone who can look at your actual data, talk to your actual users, and build actual solutions, not send you links to documentation.

If the vendor offers FDEs but charges separately for them, do the math. The upfront cost is higher, but the risk of failure is lower. A $200,000 FDE engagement that gets you to production in three months is cheaper than a $50,000 pilot that fails after six months and sets your AI initiative back a year.

Look at customer references and ask specific questions. Did they have an embedded engineer? How long did implementation take? What percentage of the work did the vendor’s team do versus internal teams? How quickly did they get to production? If the references are all “we’re still in the pilot phase” six months in, that’s a warning sign.

The Future Is Already Here

The forward deployed model isn't new, but its importance is accelerating because AI is harder to implement than traditional software. The technology is newer, so there's less institutional knowledge. The capabilities change faster, so last year's best practices are obsolete. The failure modes are different, so traditional implementation playbooks don't work.

Enterprises that build internal FDE capabilities are actually getting AI into production.

Those that rely solely on vendor support teams and their existing IT staff are getting stuck in pilot purgatory, no matter how good the underlying technology is. The difference isn't the model architecture or the feature set. It's whether you have someone who can actually get the thing working in production.

This creates a weird dynamic where the most sophisticated enterprises are investing in what looks like old-school professional services hiring.

They're bringing on engineers to do implementation work that, in theory, the vendor and existing IT teams should be able to handle together. It feels inefficient. It doesn't look like the lean, automated future everyone talks about.

But it works. It's the difference between a 95% failure rate and a 67% success rate for enterprise AI projects, according to MIT's research. Those aren't minor variations. That's the difference between a technology investment that mostly fails and one that mostly succeeds.

The irony is that this model was pioneered by companies like Palantir over a decade ago, long before the current AI wave.

They figured out that complex enterprise software couldn't be implemented the traditional way. You had to embed people who could make it work in the chaos of real organizations, navigating the politics, the legacy systems, and the resistance. Now enterprises are learning they need these same capabilities in-house.

You can't buy an AI platform and expect your existing teams to figure it out while managing their day jobs.

You need dedicated engineers who are willing to own the implementation, write production code, navigate internal politics, fix data disasters at 3 AM, and stick around until the thing actually delivers value.

That's not the future of enterprise AI. That's the present. The organizations that have figured this out are seeing ROI. The ones that haven't are drowning in failed pilots and abandoned proof-of-concepts.

Forward deployed isn't a nice-to-have. It's the difference between winning and losing in enterprise AI.

While building Moltin I have learned that the difference between an agent that ships and one that dies in a Jupyter notebook often has nothing to do with the algorithm. It's about the examples you collect.

Now I watch teams make the same mistakes we did. They spin up agents, connect APIs, write elaborate prompts. Then they wonder why the system can't handle basic variations of the task it's supposed to automate. The problem isn't the AI. It's that nobody captured the right examples when it mattered.

Most organizations building agentic AI workflows don't fail because their models are weak. They fail because they never built a proper library of task examples. Or they captured examples that were too generic to be useful, too specific to generalize, or missing the context that makes the difference between success and hallucination.

This isn't a theoretical problem. When your agent starts routing customer support tickets to the wrong department or approving expense reports it should flag, you'll trace the failure back to the same root cause: you didn't document the edge cases when you first saw them. You assumed the AI would figure it out.

It won’t.

What Makes a Good Agentic Task Example

A good task example isn't just input and output. That's what most people capture, and it's why their examples don't help. You need the full anatomy.

Start with the input, but be specific about format and constraints. If your agent processes customer emails, don't just paste "customer inquiry about refund." Include the actual email with all its typos, the subject line, the timestamp, whether it's a reply in a thread. Real inputs are messy. Your examples should reflect that.

Context is where most teams fall short. An agent deciding whether to escalate a support ticket needs to know more than the ticket content. It needs the customer's lifetime value, their support history, the current queue depth, whether it's during business hours. In agentic systems, this is called context engineering, and you need to document every piece that influences the decision.

Decision Points

Decision Points

1. Check Vendor Approval Status

Condition: Vendor must be in approved list OR have exception approval
Data sources: vendor_database, exception_log
Possible outcomes: approved_vendor / unapproved_vendor / vendor_not_found
Actual outcome: approved_vendor
Reasoning: Vendor found in approved list with active status

Decision points are the skeleton of your example. At what moment does the agent need to choose between paths? What information triggers that choice? If you're building a procurement agent that approves or rejects purchase requests, the decision point isn't just "approve or reject." It's the moment the agent checks whether the vendor is on the approved list, whether the amount exceeds department budget, whether similar requests were recently approved. Each decision point needs documentation.

Expected Output

Expected Output

Primary Decision

Decision: APPROVED
Confidence: 95%

Intermediate Steps

Validated vendor: Acme Software Ltd (ID: VND-4521)
Checked budget: $2,500 against $8,000 available in software_licenses
Verified approval authority: Auto-approve under $5,000 threshold
Generated PO: PO-2024-001234

Actions Taken
Create Purchase Order

System: ERP
PO number: PO-2024-001234
Status: Approved

Send Notifications

System: Email
Recipients: john.doe@company.com, finance@company.com
Template: expense_approved
PO attached: Yes

Update Budget

System: budget_tracker
Category: software_licenses
Amount reserved: $2,500

Audit Trail

Decision timestamp: 2024-01-15 14:25:30
Agent version: v2.3.1
Rules applied: vendor_check_v2, budget_check_v3, auto_approve_v1
Human review required: No
Response time: 1,250 ms

Expected outputs should include not just the final result but the intermediate steps. If your agent approves a purchase request, what emails does it send? What fields does it update in your ERP system? What audit trail does it create? I've seen agents produce the right answer through completely wrong reasoning. Without documented intermediate steps, you can't catch that.

Failure Modes

Failure Modes

Vendor Not in Approved List (But Is Subsidiary)

Detection: Vendor name lookup returns null
Correct behavior: Check for parent company relationship before rejecting
Risk level: Medium
Frequency: Occasional

Failure modes matter more than success cases. Every good example includes what could go wrong and how the agent should handle it. The vendor isn't on the approved list but it's a subsidiary of one that is. The budget shows as exceeded but that's because of a pending reimbursement. The request came from a VP who technically doesn't have authority for this category but everyone knows she's acting for the CFO who does. These aren't edge cases. They're Tuesday.

Metadata

Edge Case Information

Is this an edge case? No
Edge case type: N/A
Related edge cases: None

Validation

Human verified: Yes by sarah.jones@company.com on 2024-01-15
Matches policy: Yes
Policy reference: EXP-POL-2024-v3 Section 4.2
Discrepancies: None

Usage Metrics

Used in training: Yes
Used in evaluation: Yes
Times referenced: 5
Similar examples: EXP-2024-008, EXP-2024-015
Success rate on similar inputs: 94%


Notes

Capture Notes

Standard case that represents typical engineering department software purchase. Good baseline example for training.

Reviewer Notes
Clean example with all decision points clearly documented. Use as template for similar expense approval examples.

Update History

2024-01-15 14:30 by jane.smith@company.com: Initial creation from production run

Metadata ties everything together. Who captured this example and when? What version of the workflow does it represent? Has this example been used for training, evaluation, or both? Is it a real interaction or a synthetic one you created for testing? Six months from now, when you're debugging why the agent behaves oddly on certain inputs, this metadata will save you hours of archaeology.

When to Capture Examples

Timing is everything. Capture too early and you're documenting hypothetical scenarios that don't reflect reality. Capture too late and you've already deployed an agent that's learned from incomplete data.

Initial Scoping: Building Your Foundation

The scoping phase is when you define what the agent will do. This is your first chance to capture examples, and you should treat it like requirements gathering because that's exactly what it is.

Sit with the people who do the task manually today. Don't just ask them to describe it. Watch them do it. Record five to ten complete walkthroughs. Note every decision they make, every system they check, every time they pause to think. That pause is a decision point your agent will need to handle.

Think about if you were documenting a customer onboarding workflow. You’d likely work with an ops team. You would document based on what the ops team told you they did. But wait, it turns out what they described was the happy path. The actual process included a dozen conditional branches they'd internalized so completely they forgot to mention them. You would only catch this when the agent started onboarding customers incorrectly and someone said, "Well obviously it should check for that." in a Teams channel in front of leadership.

Not obvious if you never documented it.

During scoping, capture examples that span the full range of typical inputs. Don't optimize for the most common case only. You want the 80th percentile, the 95th percentile, and at least one example from the long tail. That outlier case will teach your agent how to handle variation.

Learning From the Weird Stuff

Edge cases emerge during testing and early deployment. This is when you discover all the scenarios your scoping didn't cover. The key is to have a system for capturing them immediately.

We built a feedback loop management system in Moltin. So, whenever someone on the team encounters unexpected agent behavior, they can capture it with one brief explanation and a click of the button. Moltin grabs the input, the agent's output, what the human would have done instead, and the person's explanation of why the agent got it wrong. Takes 30 seconds.

Before we had this system, edge cases lived in people's heads or got mentioned in passing during stand-ups. "Oh yeah, the agent did something weird yesterday, but I fixed it manually." That manual fix was free training data you just threw away.

Some edge cases signal systematic problems. If your expense approval agent consistently flags legitimate receipts from a particular vendor, that's not just one bad example. That's a pattern. Capture it, but also investigate the underlying cause. Maybe the vendor's invoice format confuses the OCR. Maybe their business name doesn't match what's in your vendor database. Fix the root cause and document both the edge case and the fix.

Mining Gold From Mistakes

When your agent fails, that failure is more valuable than ten successful runs. Failures reveal gaps in your example library that success can’t show you.

Root cause analysis for agent failures looks different than traditional software debugging. You’re not looking for a bug in the code. You’re looking for a gap in the agent’s understanding of the task.

• What context was missing?

• What decision point did it mishandle?

• What failure mode did you not anticipate?

Document the failure in full detail before you fix anything. Capture the complete input, the context available to the agent, every intermediate step it took, and where it went wrong. Then document what the correct behavior should have been and why. This becomes a teaching example.

Here’s a pattern I’ve seen repeatedly: an agent fails, someone patches the prompt or tweaks a parameter, the agent starts working again, everyone moves on. Six months later, the agent fails the same way on a slightly different input. Nobody remembers the original failure or the fix. You end up debugging the same problem twice.

Treat failures as permanent additions to your example library. Use them in regression testing. When you update the agent, test against your failure library first.

Letting Reality Guide You

Users will tell you when your agent gets it wrong. The question is whether you’re listening in a way that generates useful examples.

Thumbs up and thumbs down ratings are useless by themselves. A thumbs down tells you that the human felt that the agent failed. It doesn’t tell you how or why. You need structured feedback that captures what the user expected versus what they got.

When you read through the feedback in Moltin as an admin, you will want to consider the following throughout your review of the feedback:

• What did the agent do?

• What should it have done?

• Why does the difference matter?

Users can easily fill out feedback right from their chat session. Every submission should be reviewed. We are seeing about 60% become new examples that improve the agent. The other 40% reveal confusion about what the agent is supposed to do, which is also valuable.

Pay attention to the requests users make right after the agent acts. If your email triage agent routes a message to sales and the recipient immediately forwards it to support, that’s feedback. The sequence of events tells you the agent got it wrong even if the user never files a formal complaint.

Implicit feedback is everywhere if you look for it. Manual overrides of agent decisions. Cases where a user reviews the agent’s work and makes small edits. Patterns where certain types of tasks consistently get pulled back from the agent and handled manually.

All of these are examples waiting to be captured.

{
  "example_id": "EXP-2024-001",
  "example_type": "training | evaluation | debugging | stakeholder",
  "workflow_version": "2.3.1",
  "created_date": "2024-01-15T14:30:00Z",
  "created_by": "jane.smith@company.com",
  "last_updated": "2024-01-15T14:30:00Z",
  "status": "active | archived | deprecated",
  "task_description": {
    "title": "Approve departmental expense request",
    "category": "expense_approval",
    "complexity": "standard | complex | edge_case",
    "tags": ["expense", "approval", "international_vendor"]
  }
}

Practical Documentation Techniques

You need to build a system that captures rich detail without becoming a full-time job. The best system is one your team will actually use under deadline pressure.

Templates That Scale

Start with a structured template. Every example follows the same format. This makes examples easy to review, compare, and convert into training data later.

Your template should have sections for input, context, decision points, output, failure modes, and metadata. Within each section, use consistent field names. If one example calls something “customer_priority” and another calls it “account_tier,” you’ll waste time reconciling them later.

Make the template fill itself in where possible. If you’re capturing examples from a production system, pull the input and context automatically. Generate a timestamp, capture the user ID, record the agent version. Anything you can automate, automate.

Ask humans only for the parts that require judgment.

We offer a Markdown schema for our examples to be added within Moltin. This is converted into a JSON structure before being saved. Structured data is easier to search, analyze, and feed into training pipelines than free text. But you should also include a notes field for context that doesn’t fit the schema. Sometimes the most important detail is something you didn’t plan for.

Balancing Detail With Maintainability

Too much detail and nobody will capture examples. Too little and the examples won't help. You need to find the right level.

For common scenarios, you can use abbreviated documentation. Once you've captured three examples of standard expense approvals with all the detail, subsequent examples can reference the standard pattern and note only what's different.

"Same as example 0042 but with international vendor."

For unusual scenarios, go deep. These are the examples that teach your agent to handle variation. Link to relevant policy documents. Quote the exact clause in the employee handbook that governs this situation. Future you will be grateful.

Version your examples. When the workflow changes, you don't want to lose the old examples, but you also don't want to train on outdated data. We tag each example with the workflow version it represents. When we update the agent, we review examples from the previous version and decide whether to update, archive, or delete each one.

Collaborative Capture

Example capture can’t be one person’s job. It needs to be a team practice.

Make it easy for anyone to contribute. The procurement specialist who notices the agent mishandles a particular vendor type should be able to capture that example without filing out a ticket and waiting for someone from the AI team to get around to it.

But you also need curation. Not every contributed example is useful. Some are duplicates. Some document the same underlying pattern. Some are too specific to generalize. Assign someone to review new examples weekly and organize them into your library.

For example, create a two-tier system. Anyone can add an example to the staging area. Once a week, someone from your AI team reviews staged examples, tags them appropriately, and promotes them to Moltin. Examples that need clarification go back to the contributor with questions. This keeps the library clean without creating bottlenecks.

Structuring Examples for Different Purposes

Not all examples serve the same purpose. How you structure them depends on what you'll use them for.

Teaching the Agent

Examples used for training need to be clean, consistent, and representative. You’re teaching the agent patterns, so you want examples that clearly illustrate those patterns without too much noise.

For training data, focus on the input-output relationship and the intermediate reasoning steps. Context matters, but you can often simplify it. If your agent approves expenses based on ten different factors, but only three factors matter for 90% of decisions, your training examples should emphasize those three.

Balance your training set. If 95% of your examples are approvals and 5% are rejections, your agent will be biased toward approval. You might need to create synthetic examples or oversample the minority class.

Label your training examples clearly. Don’t just mark them “correct.” Explain why they’re correct. What principle or policy does this example illustrate? What pattern should the agent learn? These labels help you audit your training data later when the agent behaves unexpectedly.

Measuring Performance

Evaluation examples are your test suite. They tell you whether changes to the agent make things better or worse.

These examples should be stable. Don't change them unless the underlying task changes. You want to be able to compare agent performance across weeks or months, and that requires a consistent benchmark.

Include both typical cases and edge cases in your evaluation set. A good split is 70% typical, 20% challenging but not rare, 10% true edge cases. This gives you a sense of both baseline performance and how well the agent handles difficulty.

For each evaluation example, define success criteria precisely. "Correct output" is too vague. Does correct mean exact match? Semantically equivalent? Within certain parameters? The more specific your criteria, the more useful your evaluation metrics will be.

Understanding Failures

When something goes wrong in production, you need examples that help you diagnose the problem quickly.

Debugging examples should include everything. Full input, complete context, every intermediate step, the final output, and what went wrong. These are not clean training examples. They’re crime scenes. You’re preserving evidence.

Tag debugging examples with the symptoms.

• “Agent approved expense over budget limit.”

• “Agent routed technical question to sales.”

• “Agent generated response in wrong language.”

These tags let you find similar failures quickly when you’re troubleshooting.

Cross-reference debugging examples with the fixes you apply. When you solve a problem, link the solution back to the examples that revealed it. This builds institutional knowledge. Six months from now, when a new team member encounters a similar issue, they can see not just what went wrong but how it was fixed.

Building Trust

Some examples exist primarily to show non-technical stakeholders what the agent does and how it works.

These examples should tell a story. Walk through a complete scenario from start to finish. Show the input, explain what the agent considers, describe the decision it makes, and demonstrate the outcome. Make it concrete enough that someone who doesn’t understand AI can follow along.

Use stakeholder examples to manage expectations. If your agent handles routine cases but escalates complex ones, show examples of both. If it sometimes gets things wrong in predictable ways, document those too. Transparency builds trust more than pretending the system is perfect.

Update stakeholder examples when the agent’s behavior changes. These examples shape how people think about what the agent can do. Outdated examples create confusion and erode trust when reality doesn’t match the documentation.

Building Your Library From Day One

Start capturing examples before you spin up your first workflow. The examples come first. They define what success looks like.

In your first week, capture 20 examples by hand. Sit with the people who do the task today. Watch them work. Document exactly what they do. These 20 examples become your specification. They tell you what the agent needs to learn.

Set up your capture infrastructure early. The simple Slack workflow. The JSON schema. The staging and review process. Make it easy to add examples from day one because you'll never have time to go back and add them later.

Treat your example library as a product. It needs maintenance. Examples become stale. Workflows change. Policies update. Schedule quarterly reviews where you go through your library and archive or update examples that no longer reflect current reality.

The teams that ship great agentic AI systems aren't the ones with the fanciest agents and models. They're the ones that captured the right examples at the right time and built a library that grows smarter as the agent does. Start building yours today, because the best time to capture an example is the first time you see it.

Visit Moltin

Everyone's talking about agentic AI. The term shows up in pitch decks, product launches, quarterly planning meetings and LinkedIn posts about the future of work. But most discussions skip past a basic question: what actually makes a task "agentic" in the first place?

Not every workflow benefits from an agent. Some tasks need simple automation. Others require human judgment from start to finish. The sweet spot for agentic systems sits somewhere between these extremes, where three specific characteristics converge.

Building Moltin has taught me to ignore the noise. LinkedIn posts fade, but architectural requirements don't. So let's cut through the hype and examine what separates genuinely agentic tasks from everything else.

Visit Moltin

Sustained Multi-Step Interaction

True agentic tasks can't be solved in a single pass. They require multiple actions, decisions, and responses over time. Think about how you'd book a complex business trip. You check flights, compare prices, verify hotel availability, adjust for meeting schedules, and revisit earlier choices when conflicts emerge.

Each step informs the next one. The system can't just execute a predetermined sequence and call it done. It needs to maintain context across interactions. What happened in step three matters when you're on step seven.

This is different from a simple API call. It's different from running a script. The task has depth. It unfolds. A traditional automation might handle one piece of this puzzle, but an agent manages the entire progression.

The duration matters too. Some agentic tasks take minutes. Others span hours or days. The key isn't the time itself but whether the system can pick up where it left off. Can it remember what it learned? Can it reference earlier decisions?

Consider customer support. A single FAQ answer isn't agentic. But diagnosing a complex technical issue over multiple messages, gathering information from different sources, trying solutions, and adapting based on results? That's sustained interaction.

The system needs memory. Not just logs, but working memory that shapes ongoing behavior. When a person says "that didn't work", the agent should know what "that" refers to without asking you to repeat the entire history.

Partial Observability

Agentic tasks operate in environments where the system can't see everything at once. Information is hidden, incomplete, or emerges only through interaction. You're solving a puzzle without seeing all the pieces.

A chess engine doesn't face partial observability. It sees the entire board. Every piece, every legal move. That's full observability, even if the problem is computationally hard. An agent booking your travel? It doesn't know your actual preferences until it asks. It can't see your calendar conflicts until it checks. Flight prices change while it's thinking.

This creates genuine uncertainty. The agent must act without complete information. It forms hypotheses, tests them, and updates its understanding. Sometimes it guesses wrong. That's not a bug, it's the nature of the problem.

Think about competitive intelligence research. You're trying to understand a competitor's strategy, but you can only see public information. Press releases. Job postings. Product updates. Each data point gives you a glimpse, never the full picture. An agent tackling this task must synthesize fragments into a coherent view.

Medical diagnosis works the same way. Symptoms are clues, not answers. Test results narrow the possibilities but rarely offer certainty. A diagnostic agent orders tests based on probabilities, interprets results in context, and adjusts its thinking as new information arrives.

The challenge compounds when the environment changes during execution. Markets shift. Servers go down. People change their minds. Your agent started with incomplete information, and now that incomplete information is also outdated.

Welcome to the real world.

Partial observability forces agents to be strategic about information gathering. What should I check first? Which questions will reduce uncertainty the most? There's a cost to every query, whether that's time, money, or cognitive load on a human in the loop.

Adaptive Strategy Refinement

The final piece is adaptation. Agentic tasks don't have a fixed solution path. The approach must evolve based on what the agent discovers along the way. Plan A fails, so you try Plan B. Then you realize Plan C would've been smarter from the start.

This goes beyond simple branching logic. If-then statements don't cut it. The agent needs to reason about which strategies will work in the current context. It adjusts not just its actions but its entire approach to the problem.

Consider content moderation at scale. You can't write rules for every edge case. The agent must learn patterns, recognize when those patterns break down, and develop new approaches. A technique that worked yesterday might fail today because bad actors adapted. Your agent needs to adapt faster.

Software debugging is another clear example. You don't know where the bug is, so you form a hypothesis. You add logging, run tests, examine outputs. Each result tells you something. Sometimes it confirms your theory. Sometimes it forces you to rethink everything. An effective debugging agent refines its strategy based on what each experiment reveals.

The refinement happens at multiple levels. Tactically, the agent adjusts its immediate next steps. Strategically, it reconsiders its overall approach. Sometimes it realizes the entire problem framing was wrong and needs to step back.

This is where machine learning and reasoning intersect. The agent might use learned patterns to guide initial strategies. But it also needs explicit reasoning about whether those patterns apply to the current situation. Pure learning can be brittle. Pure logic can be inflexible. Agentic systems blend both.

Human feedback becomes crucial here. An agent that can't learn from correction will keep making the same mistakes. But one that updates too aggressively based on every comment will thrash between strategies. The right balance is task-dependent and often requires careful tuning.

Why All Three Matter

Remove any one of these requirements and you lose the “agentic” quality. A multi-step process with full observability? That’s just a complex algorithm. Partial observability without adaptation? That’s pattern matching under uncertainty. Adaptation without sustained interaction? That’s reinforcement learning on individual decisions.

The combination creates emergent behavior that feels genuinely intelligent. The system doesn’t just react, it pursues goals. It doesn’t just execute, it strategizes. When things go wrong, it figures out why and tries something different.

This is why not everything should be agentic. Simple tasks with clear paths and complete information don’t need this machinery. Adding an agent adds complexity, failure modes, and costs. Use the simplest tool that solves the problem.

But when all three requirements align, agents shine. They handle the tasks that traditionally required human judgment not because they’re magic, but because the problem structure demands exactly the capabilities agents provide.

Building for Agentic Tasks

If you’re designing systems for agentic work, these requirements have practical implications. Your architecture needs state management for sustained interaction. It needs sensors and probes for gathering information in partially observable environments. It needs reasoning components that can evaluate and switch strategies.

You also need observability into the agent itself. When an agent makes a decision, can you trace why? When it shifts strategies, can you see what triggered the change? Black box agents are hard to trust and harder to improve.

Testing gets more complex too. Unit tests aren’t enough. You need scenarios that play out over time, with realistic information hiding and strategy challenges. This means simulation environments and evaluation frameworks that go beyond accuracy metrics.

The human-agent interface becomes critical. People need to understand what the agent is doing without watching every action. They need to provide guidance without micromanaging. They need override capabilities when the agent goes off track. This is interaction design, not just UX polish.

The Real Test

Here’s how to know if a task is genuinely agentic. Ask yourself: could you write a flowchart that solves this task completely? If yes, it’s automation, not agency. Could you solve it with a single large language model call? If yes, it’s generation, not agency.

Agentic tasks resist simple decomposition. They’re messy. They require judgment. The path from start to finish isn’t straight, and you can’t see it all from the beginning. That’s exactly when you need an agent.

The three requirements I’ve outlined aren’t arbitrary. They emerge from the fundamental structure of problems that demand adaptive, goal-directed behavior over time. Get comfortable with these concepts and you’ll stop chasing agentic solutions for problems that don’t need them.

You’ll also recognize the problems that do. And those are the ones where agents don’t just add value, they transform what’s possible.

Visit Moltin

Introduction

Workflows are only as smart as the way they're configured. In Moltin, you can orchestrate AI agents to handle complex tasks, but how those agents execute tasks matters just as much as what they do. The Skill Settings Execution Options let workspace admins fine-tune three critical aspects of how their workflows run: whether tasks happen one after another or all at once, which AI engine handles the processing, and what happens when something breaks.

These aren't buried toggles in a settings submenu. They're strategic choices that shape everything from how fast your workflows complete to how reliably they recover from errors. Get them right and your agents work like a well-oiled machine. Get them wrong and you'll spend more time debugging than deploying.

Execution Mode: Sequential, Parallel, or Let the AI Decide

Execution Mode controls the fundamental flow of your workflow. Do tasks line up and wait their turn, or do they all fire at once? Or should Moltin's AI figure it out based on task dependencies?

Benefits

The right execution mode can transform a sluggish workflow into something responsive. Sequential execution works when tasks depend on each other. If Agent A needs to finish analyzing a document before Agent B can summarize it, you can't run them simultaneously. That's where sequential shines. It ensures each task completes before the next one starts, maintaining strict order and preventing data conflicts.

Parallel execution does the opposite. It runs multiple independent tasks at the same time. If you've got five agents all pulling different data sources with no overlap, why make them wait? Parallel mode can cut your workflow completion time dramatically. A workflow that took fifteen minutes running tasks one by one might finish in three when tasks run simultaneously.

Intelligent mode is where Moltin gets interesting. The system analyzes your workflow's task dependencies and makes real-time decisions about which tasks can run in parallel and which need to wait. You don't have to map out the entire dependency tree yourself. The AI handles it. This matters most for complex workflows where some tasks depend on others but many don't. Intelligent mode balances speed with correctness, running parallel tasks when possible while respecting dependencies.

How to Use Execution Mode

Open your workflow settings by clicking the gear icon in the bottom right corner of your agent’s editor canvas. You'll see Execution Mode near the bottom of the Skill Settings modal. Click the dropdown menu. Three options appear: Sequential, Parallel, and Intelligent.

Choose Sequential if your workflow has tasks that must complete in a specific order. This is common in data processing pipelines where each step transforms the output of the previous one. Pick Parallel if you're confident your tasks don't depend on each other's results. This works well for workflows that gather information from multiple sources independently. Select Intelligent when you're not sure or when your workflow has a mix of dependent and independent tasks. Let Moltin's AI optimize the execution order for you.

After selecting your mode, update the settings and your change takes effect immediately. Your next workflow run will use the new execution mode.

Engine Type: Langchain or DSPy

Engine Type determines which AI framework powers your workflow. Langchain and DSPy take fundamentally different approaches to how language models process tasks.

Benefits

Langchain is the more mature option. It's a modular orchestration framework that chains together language model calls, data retrieval, and tool use. Langchain helps chain together interoperable components and third-party integrations to simplify AI application development, making it solid for workflows that need to connect multiple data sources, APIs, or external tools.

If your workflow pulls data from a CRM, queries a knowledge base, and then generates a report, Langchain handles those integrations smoothly. It's also got extensive documentation and a large community, so troubleshooting is easier.

DSPy takes a different route. Instead of manually crafting prompts for each task, DSPy allows you to iterate fast on structured code rather than brittle strings and offers algorithms that compile AI programs into effective prompts.

This means less time tweaking prompt language and more time focusing on what you want the AI to accomplish. DSPy automatically optimizes prompts based on your workflow's performance metrics. If a task isn't getting the results you want, DSPy's built-in optimizers can adjust the prompts without you touching them.

Here's where the practical difference shows up. Use Langchain when your workflow needs heavy data integration or when you're connecting to many external services.

For example, a customer support workflow that needs to query Zendesk tickets, search internal documentation, and update a Salesforce record would benefit from Langchain's extensive integration library.

Choose DSPy when your workflow involves multiple LLM calls that need to work together reliably. A research assistant workflow that extracts information from documents, synthesizes findings, and generates structured reports would perform better with DSPy's automatic prompt optimization.

DSPy also shows lower framework overhead in benchmarks, with DSPy showing the lowest framework overhead at approximately 3.53 milliseconds compared to Langchain's approximately 10 milliseconds.

How to Use Engine Type

In the same Skill Settings modal, locate the Engine Type option below Execution Mode. Click the dropdown. You'll see two choices: Langchain and DSPY.

Select Langchain if your workflow relies on integrating multiple external data sources, APIs, or tools. It's the safer bet for production workflows that need broad compatibility.

Pick DSPY if your workflow makes multiple language model calls and you want those calls optimized automatically. It's especially useful for workflows still in development where you're iterating on task definitions.

The engine type change applies to the next workflow run. You can switch engines anytime to compare performance. Some teams run A/B tests with the same workflow on different engines to see which performs better for their specific use case.

Continue on Error: Keep Going or Stop Everything

Continue on Error decides what happens when a task fails. Should the workflow halt completely, or should it mark the failed task and move on to the next one?

Benefits

Without Continue on Error enabled, a single failed task stops your entire workflow. That's fine for workflows where every task is critical. If you're processing financial transactions and one step fails, you probably want everything to stop so you can investigate. But many workflows don't need that level of rigidity.

With Continue on Error turned on, failed tasks get marked as failed and the workflow proceeds. The system logs the error details so you can review what went wrong later. This is crucial for workflows that process multiple independent items.

Imagine a workflow that analyzes a hundred customer reviews. If review number 32 causes an error (maybe it's malformed data or an unexpected format), you don't want the other 99 reviews sitting unprocessed. Continue on Error lets the workflow finish the rest and flags the problematic review for manual review.

This setting particularly matters for long-running workflows with many tasks. A workflow with fifty tasks that takes an hour to complete becomes a debugging nightmare if you have to restart it from scratch every time a single task hiccups. Continue on Error turns that nightmare into a manageable process: run the workflow, review which tasks failed, fix those specific issues, and rerun just the failed tasks.

How to Use Continue on Error

Find the Continue on Error toggle switch in your Skill Settings panel, beneath the Engine Type dropdown. It's a simple on/off switch.

Turn it on when your workflow processes multiple independent items or when individual task failures shouldn’t block the entire workflow. This is common in batch processing scenarios, data enrichment workflows, or content generation tasks. Leave it off when every task is critical and a failure in one task means the entire workflow’s output is unusable. Financial calculations, compliance checks, and sequential data transformations usually fall into this category.

When Continue on Error is enabled and a task fails, check your workflow execution logs. Failed tasks show up clearly with error details. You can identify patterns (maybe a specific data format always fails), fix the underlying issue, and rerun the workflow or manually reprocess the failed tasks.

Putting It All Together

These three settings work together. A workflow using Intelligent execution mode with DSPy and Continue on Error enabled can adapt its execution order, optimize its prompts automatically, and keep running even when individual tasks fail. That's a resilient, self-optimizing system. Conversely, a workflow using Sequential execution with Langchain and Continue on Error disabled prioritizes strict control and consistency over speed and fault tolerance.

Your choice depends on what you're building. High-stakes workflows that can't tolerate any errors need the conservative approach. Experimental workflows that process large volumes of varied data benefit from the more adaptive settings. The beauty of Moltin's Workflow Settings is that you can change these options anytime. Try different combinations. Measure what works. Optimize based on real performance, not assumptions.

Visit Moltin

The enterprise software landscape is about to experience its most significant disruption in decades, and it won't come from the incumbents. While Salesforce, SAP, and Workday rush to add AI features to their existing platforms, a new category of infrastructure is emerging. A category that will fundamentally reshape where value accrues in the enterprise stack.

This new layer, built around context graphs and decision traces, represents a rare opportunity: the chance to build a trillion-dollar platform from scratch. But the window is narrow, the technical challenges are real, and the competitive dynamics favor a specific type of player.

Visit Moltin

Why Incumbents Are Structurally Disadvantaged

The legacy enterprise vendors are not standing still. They're acquiring AI startups, building agent features, and restricting API access to protect their moat. On paper, they have every advantage: existing customer relationships, comprehensive data models, and the resources to out-invest any startup.

Yet they face a structural problem that acquisitions and defensive tactics cannot solve.

The Execution Path Problem

Capturing decision traces requires being in the execution path at the precise moment decisions are committed. This isn't about observability after the fact or governance bolted on top. It's about instrumenting the decision itself and capturing the complete context as the agent queries multiple systems, synthesizes information, applies judgment, and commits the result.

Incumbents own deep data about customers, opportunities, and pipelines. But the decisions that matter increasingly span multiple systems. A sales exception might depend on data from Salesforce (customer history), NetSuite (financial health), Gong (recent call sentiment), and Slack (internal communications about churn risk). Any one of these incumbents only sees one piece of this picture. They cannot capture the cross-system synthesis that justifies the decision without fundamentally changing their position in the stack.

The incumbents could try to become the orchestration layer where these decisions happen. But this requires them to effectively demote themselves from system of record to middleware. This is a business model transformation that large public companies rarely execute successfully.

Consider what this would actually require for a company like Salesforce. Their entire business model is built around owning customer data, charging per-seat licenses, creating switching cost lock-in, and expanding within their domain. To become an effective orchestration layer, they would need to open APIs freely, enable data to flow easily to competitors, charge for coordination rather than storage, and accept that their value comes from connecting systems rather than replacing them.

These are fundamentally opposed business models. Wall Street values Salesforce based on annual recurring revenue from seat licenses and expects growth through expanding Salesforce's footprint. The moment Salesforce becomes a coordination layer that helps customers use competitors more effectively, an analyst asks: "Your revenue per customer is declining because customers are using Salesforce for less. Why should we value you as a high-growth SaaS company?" The CEO has no good answer. The business model transformation would damage their valuation before the new model proves itself.

We've seen this pattern before. IBM owned the mainframe—the central system of record for enterprise computing. When the market needed distributed computing across many systems, IBM should have embraced being a coordination layer in a multi-vendor world. Instead, they tried to protect mainframe revenue while half-heartedly building distributed solutions. They had the technical capability to lead but lost platform leadership to Microsoft and Oracle because the business model transformation was too threatening to their core revenue.

This structural challenge is precisely why the decision orchestration layer is more likely to emerge from startups with no legacy revenue to protect, native multi-system design from day one, and investor expectations aligned with disrupting incumbents rather than protecting them. Their incentive is to keep AI features within their walled gardens, even though the most valuable decisions require breaking down those walls.

The API Restriction Trap

When threatened, incumbents predictably restrict API access, impose rate limits, and favor their own AI features. We've seen this playbook before. But in trying to protect their existing business, they make it harder to build the cross-system context graphs that enterprises actually need.

This creates an opening. Enterprises will choose platforms that can see across systems over platforms that try to own everything. The vendor that sits between AI agents and multiple systems of record (capturing context from all of them) becomes more strategically valuable than any single system of record, no matter how comprehensive.

Why Data Platforms Aren't Positioned to Win

If incumbents struggle with the execution path problem, what about data platforms? Snowflake, Databricks, and the modern data stack companies already aggregate information across systems. They sit on comprehensive data. Why can't they capture decision traces?

The Write Path vs. Read Path Problem

Data warehouses and lakehouses operate in the read path. They're optimized for analytical queries after data has been written to source systems. They're extraordinary at aggregation, transformation, and analysis. But decision traces must be captured at commit time, in the write path, at the speed of transaction processing.

When an AI agent approves a purchase order, the context that justified that decision must be captured in real-time, before the state of the world changes. By the time that data flows into a data warehouse (hours or days later, after ETL processes run) the moment has passed. You can reconstruct what data existed, but you cannot perfectly preserve the temporal snapshot and cross-system relationships that made the decision appropriate.

Data platforms could try to move upstream into the operational/transactional layer. But this requires different technical architecture, different performance characteristics, and different go-to-market motions.

Consider the fundamental architectural divide. Data warehouses are built for columnar storage optimized for scanning millions of rows, batch processing with eventual consistency, and high latency tolerance where queries can take seconds or minutes. Operational systems require row-oriented storage for fast individual record updates, real-time consistency, and millisecond latency where users are actively waiting. These aren't different configurations, they're fundamentally different architectures.

The performance requirements are equally incompatible. When an AI agent approves a purchase order, the entire workflow (querying vendor status, checking budget availability, validating policy, capturing decision context, and committing the approval) must complete in tens of milliseconds. The user is waiting. If this takes five seconds instead of 40 milliseconds, the experience is broken and the agent cannot function in production workflows. Data platforms excel at queries that scan 500,000 rows and take 13 seconds to return dashboard results, which is perfectly acceptable for analytics but catastrophic for operational decisions.

This matters critically for context graphs because capturing decision traces must happen at transaction speed, not analytical speed. By the time data flows through ETL pipelines into a warehouse hours later, the moment has passed. Customer tiers may have changed, budgets updated, policies revised. You cannot reconstruct the exact state of the world at decision time from analytical data that arrives after the fact.

The go-to-market challenge is equally significant. Data platforms sell to Chief Data Officers and analytics teams with a value proposition around strategic insights, six to twelve month buying cycles, and success metrics like reports created and query performance. Operational platforms sell to CIOs and line of business leaders with a value proposition around daily execution, three to six month cycles, and success metrics like transaction throughput and uptime. These are different buyers, different conversations, different implementation partners, and different value propositions entirely.

A platform built for analytics would face immediate credibility questions from operations leaders: "Why should we trust our operational systems to a platform built for analytics? What happens when analytical queries slow down our transactional performance?" This is why Amazon built DynamoDB and Redshift as separate products with separate architectures rather than trying to make Redshift handle real-time transactions. It's not where their core competency lies.

Pathways for a Startup

This leaves a genuine opening for startups, but the path to a trillion-dollar outcome is not obvious. We're seeing two distinct approaches emerge, and the winner may be neither, or a hybrid we haven't seen yet.

Path One: Replace Systems of Record

The most direct approach is to rebuild CRMs, ERPs, and other systems of record from the ground up with agentic execution and context capture as core design principles. Instead of a CRM that stores customer data and bolts on AI features, imagine a system where AI agents are first-class users, decisions are captured as core entities, and context graphs are native infrastructure.

This approach has the virtue of clarity. You own the data, control the execution path, and can design the perfect architecture for context capture without legacy constraints. Companies taking this path are essentially saying: "Incumbent-X had 25 years to build the right architecture for AI. They didn't. We will."

The challenge is obvious: you're competing with entrenched vendors on their home turf while simultaneously trying to introduce a new technical paradigm. You need to be 10x better on the AI/context dimensions while also achieving feature parity on the traditional dimensions. The switching costs are enormous, and most enterprises aren't ready to rip out and replace core systems, even for significantly better AI capabilities.

Path Two: Build the Orchestration Layer

The alternative is to sit between AI agents and existing systems of record. Don't replace Salesforce or Snowflake, orchestrate on top of it. When agents need to make decisions that span CRM, ERP, support, and financial systems, your platform becomes the execution layer. You query the systems of record, capture the decision context, commit the results back, and maintain the context graph that makes future decisions smarter.

This approach sidesteps the replacement problem. Enterprises can adopt your platform without ripping out existing infrastructure. You provide immediate value (better AI decisions) without requiring enterprise-wide transformation. You accumulate context graphs that become more valuable over time, creating a moat that's orthogonal to the data moats of traditional vendors.

The challenge here is that you don't own the underlying data. You're dependent on APIs that can be restricted. You're building on top of systems that weren't designed for this use case. And you need to be so valuable that enterprises choose you even when incumbents offer "good enough" agent features bundled into existing contracts.

The Emerging Category

The winning approach will likely be something that defies existing categories. Not quite observability (though it requires instrumentation). Not quite a data warehouse (though it captures cross-system context). Not quite a CRM or ERP (though it sits at the center of business operations).

Think of it as a "decision fabric".

An infrastructure that captures, stores, and makes queryable the complete context of business decisions across an organization. It needs real-time performance for the write path, sophisticated graph capabilities for modeling relationships, temporal consistency for audit and learning, and cross-system reach that no incumbent naturally possesses.

The companies building this category today (like Moltin) are placing a bold bet: that in five years, the most valuable enterprise platform won't be the one that stores the most customer records or the biggest data lake, but the one that has the richest, most complete record of how decisions are actually made.

The Strategic Stakes

If this thesis is correct (and the early evidence is compelling) we're witnessing the emergence of a new control point in enterprise architecture. The platform that captures decision context becomes the source of truth for AI autonomy, the system of record for institutional judgment, and the layer that incumbents must integrate with even as they compete.

This is why context graphs represent a trillion-dollar opportunity. Not because they'll generate a trillion dollars in revenue (though they might), but because they'll fundamentally restructure where value and power reside in the enterprise stack.

For incumbents, the challenge is existential: adapt to a world where they're not at the center, or watch a new generation of platforms capture the most strategically valuable layer of the stack.

For startups, the opportunity is generational: build the infrastructure that makes AI autonomy possible, and you don't just build a successful company, you build the next platform that everything else is built on top of.

The race has started. The technical challenges are significant. The competitive dynamics are complex. But the prize for getting it right has rarely been larger.

Visit Moltin

At Moltin, our AI agents are rapidly moving from team-driven experimental prototypes to fully supported and operationalized production systems handling real business workflows. We are deploying agents that approve expense reports, manage the support ticket life cycle, route and respond to sales leads, and make countless other operational decisions. Yet despite the excitement and investment, these agents are hitting an invisible wall. A wall that governance frameworks and data access alone cannot solve.

The Data Paradox

At first glance, modern AI agents appear to have everything they need. They connect to CRMs, ERPs, support platforms, and data warehouses. They can read customer records, check shipment ETAs, review past transactions, and pull up policy documents. The data is there. The integrations work. So why do agents still struggle to make reliable decisions in complex scenarios?

The answer lies in what's missing: decision traces.

While organizations meticulously capture what happened (every transaction, status change, field update etc.), they systematically fail to capture why it happened. The context that justified a decision, the exceptions that were made, the competing priorities that were balanced—all of this evaporates the moment a decision is executed.

When Decisions Become Black Boxes

Consider a common scenario. A customer support agent (human or AI) needs to decide whether to escalate a refund request that exceeds standard policy limits. The decision gets made. The refund gets processed. The ticket gets closed. But what happened to the reasoning?

Perhaps the customer was a high-value enterprise client in the middle of a renewal negotiation. Maybe there was a known product bug affecting their account. The support manager might have considered recent churn rates in that customer segment, or referenced a similar exception made last quarter for a comparable situation. All of this context informed the decision, but none of it gets captured in the systems of record.

Six months later, when a similar case appears, that institutional knowledge is gone. The AI agent can see that an exception was made, but it cannot understand why the exception was justified. It cannot replay the state of the world at the moment of decision. It cannot use past precedent to guide current judgment.

The Audit Problem

This absence of decision traces creates a cascade of problems. The most immediate is auditability. When an AI agent makes a controversial decision, stakeholders inevitably ask: "Why did the system do that?" Without decision traces, there's no good answer. You can examine the current state of the data, but you cannot reconstruct what the agent knew or considered at decision time.

Was the customer tier different then? Had the SLA been recently updated? Was there an active incident affecting service levels? These contextual factors might have made the decision entirely reasonable, but if they're not preserved, the decision appears arbitrary or wrong in hindsight.

The Learning Problem

The lack of decision traces also prevents organizational learning. Every decision an organization makes (especially edge cases and exceptions) represents valuable information about how policies should adapt to reality. But without capturing why decisions were made, this learning cannot happen systematically.

Organizations end up in a loop where the same exceptional cases require the same manual intervention repeatedly. The knowledge exists in someone's head or in a Slack channel, but it never makes it into the systems that guide future decisions. AI agents, no matter how sophisticated, cannot learn from precedent they cannot access.

The Cross-System Context Challenge

The problem becomes even more acute when decisions depend on information scattered across multiple systems. A purchasing approval might hinge on budget data from the ERP, project timeline information from the project management tool, vendor performance metrics from the procurement system, and strategic priorities discussed in executive meeting notes.

Each system captures its slice of the truth, but no single system sees the complete picture that justified the decision. The AI agent can query these systems individually, but it cannot reconstruct the synthesis of information that led to the original judgment. The connective tissue between data points (the reasoning that tied them together) never existed in machine-readable form.

Why Governance Isn't Enough

Many organizations respond to these challenges by adding more governance: approval workflows, guardrails, human-in-the-loop checkpoints. These controls are necessary, but they don't solve the underlying problem. Governance can prevent bad decisions from being executed, but it cannot help agents make better decisions in the first place. It’s like putting a fence around a problem rather than solving it.

More fundamentally, governance after the fact cannot capture decision context. By the time a decision reaches an approval step, the full reasoning behind it is rarely documented. The approver makes a judgment call based on their own knowledge and experience, and that context disappears just as surely as the original agent's reasoning.

The Path Forward… A System of Precedents

The solution requires a hard look at how we think about business systems. We need infrastructure that captures not just the results of decisions, but the complete context that justified them. This means preserving the state of relevant data at decision time, recording the factors that were considered, documenting the precedents that were referenced, and maintaining the links between related decisions over time.

This isn't about logging every AI model inference or storing verbose chain-of-thought outputs. It's about building a system that treats decisions as first-class entities. A system with its own lifecycle, its own relationships, and its own place in the organizational memory.

Only when we solve this problem can AI agents move beyond executing simple, predefined workflows to making the kind of nuanced, context-aware judgments that complex business operations require. The data is necessary but not sufficient. What we need is a record of how that data was interpreted, synthesized, and applied. A decision trace that makes institutional knowledge not just preserved, but actionable for the agents we're building today and tomorrow.

This is 1.2 of our Enterprise AI Leadership Series. In 1.1 we explored the foundational concepts leaders need to understand about traditional automation. Today, we dive deeper into the critical evolution from traditional automation to artificial intelligence and why this shift represents the most significant business transformation in decades.

The transition from traditional automation to artificial intelligence represents more than technological advancement—it's a fundamental shift in how systems process information and make decisions. Where rule-based systems follow explicit instructions, AI systems recognize patterns in data and make intelligent inferences about new situations based on what they've learned from past examples.

This difference is profound and transformative. Traditional systems ask, "What rule applies to this situation?" AI systems ask, "What patterns do I recognize, and what's the most likely appropriate response based on everything I've learned?" This shift enables capabilities that seem almost magical compared to traditional automation.

Learning Without Programming

AI systems can improve their performance by analyzing data and identifying patterns that human programmers might never have considered. A machine learning system analyzing customer behavior might discover that customers who purchase certain combinations of products are significantly more likely to become long-term, high-value clients—a pattern that would require months of manual analysis to identify and years to codify into traditional rules.

Adaptation Through Experience

Unlike rule-based systems that operate identically from their first day to their last, AI systems evolve and improve over time. They identify which approaches work best in different situations, learn from mistakes, and gradually become more accurate and effective. A fraud detection AI system doesn't just apply preset rules—it continuously learns new fraud patterns, adapts to criminal innovations, and becomes more sophisticated in distinguishing between legitimate and suspicious activities.

Contextual Understanding

Modern AI systems can consider vast amounts of contextual information when making decisions. They can understand that the same customer inquiry might require different responses depending on the customer's history, current market conditions, recent company announcements, or even the time of year. This contextual awareness enables more nuanced, appropriate, and effective responses.

Ambiguity Navigation

Perhaps most importantly, AI systems can function effectively in ambiguous situations where traditional automation would fail. They can make reasonable decisions even when faced with incomplete information, contradictory signals, or entirely novel scenarios. They operate on probability and confidence levels rather than binary true/false logic.

The Three Evolutionary Branches of AI

The evolution from traditional automation to AI hasn't followed a single path. Instead, it has branched into three distinct categories, each addressing different aspects of business intelligence and automation needs.

Traditional AI (The Pattern Masters)

Traditional AI, also known as "narrow AI" or "discriminative AI," represents the first major step forward beyond rule-based systems. These systems excel at recognizing patterns in data, making predictions about future outcomes, and optimizing decisions within specific domains.

Traditional AI systems are the recommendation engines that suggest products you might want to buy, the fraud detection systems that identify suspicious transactions, and the predictive maintenance programs that prevent equipment failures before they occur. They analyze vast amounts of historical data to identify patterns and relationships that human analysts would find difficult or impossible to detect.

What makes Traditional AI extremely valuable is its ability to find signal in noise—to identify meaningful patterns in data that appears random or chaotic to human observers. A Traditional AI system analyzing retail sales data doesn't just track what products are selling; it identifies subtle correlations between customer demographics, seasonal patterns, economic indicators, weather conditions, and purchasing behavior to predict demand with remarkable accuracy.

Generative AI (The Creative Engines)

Generative AI represents a more recent and dramatic innovation—systems that don't just analyze existing content but create entirely new content. These are the systems that can write articles, generate images, compose music, draft legal documents, and produce code based on natural language descriptions.

The revolutionary aspect of Generative AI isn't just its creative capability, but its natural language interface. For the first time, business users can interact with sophisticated AI systems using plain English rather than learning complex software interfaces or programming languages. You can ask a Generative AI system to "Write a proposal for expanding our European operations, including market analysis, financial projections, and risk assessment," and receive a comprehensive document that serves as an excellent starting point for strategic planning.

This capability transforms how organizations approach content creation, communication, and knowledge work. Instead of having specialists create every document, presentation, and analysis from scratch, teams can use Generative AI to produce first drafts, generate alternatives, and explore possibilities at speeds previously impossible.

Agentic AI (The Autonomous Decision Makers)

Agentic AI represents the newest and most ambitious technology—systems that can not only analyze data and create content but also take autonomous actions and manage complex, multi-step processes. These systems work backward from desired outcomes, determining the best strategies to achieve objectives and executing those strategies with minimal human intervention.

Agentic AI systems can manage entire business processes end-to-end. They might handle supply chain optimization by monitoring global conditions, predicting disruptions, automatically adjusting orders with suppliers, rerouting shipments, and updating stakeholders—all while continuously optimizing for cost, quality, and delivery time constraints.

What distinguishes Agentic AI is its goal-oriented behavior and autonomous operation. While Traditional AI identifies patterns and Generative AI creates content, Agentic AI takes action. It can coordinate multiple systems, make decisions based on changing conditions, and execute complex strategies that adapt to real-world dynamics.

Strategic Implications for Enterprise Leaders

The business landscape is undergoing a fundamental shift that demands immediate leadership attention and strategic response. While many organizations have spent the past decade implementing traditional automation to reduce costs and improve efficiency, we are now entering an era where artificial intelligence transforms not just how work gets done, but what becomes possible. This evolution from simple process automation to true machine intelligence represents one of the most significant competitive inflection points in modern business history. Organizations that recognize this transition early and act decisively will establish market advantages that may prove insurmountable for slower-moving competitors. The question is no longer whether AI will reshape your industry—it's whether your organization will lead that transformation or be displaced by it.

Competitive Landscape Transformation

Understanding this evolution from automation to intelligence isn't merely an academic exercise—it's essential for maintaining competitive advantage in rapidly changing markets. Organizations that successfully navigate this transition will gain significant advantages over those that remain anchored in traditional automation approaches.

The competitive dynamics are already shifting dramatically. Companies using AI-powered customer service can provide 24/7 support that's more sophisticated and helpful than traditional call centers. Organizations deploying Generative AI for content creation can produce marketing materials, documentation, and communications at speeds and scales that overwhelm competitors still relying on manual processes. Businesses implementing Agentic AI for operations can respond to market changes and customer needs with agility that traditional competitors cannot match.

Investment Imperative

The transition from automation to intelligence requires different investment strategies and thinking. Traditional automation projects typically involved large upfront costs for software licenses and implementation, followed by relatively predictable operational expenses. AI initiatives often require different approaches—cloud-based services with usage-based pricing, continuous learning and adaptation processes, and ongoing optimization rather than one-time implementations.

The return on investment calculation also changes fundamentally. Traditional automation delivered value through cost reduction and efficiency gains that could be easily quantified. AI systems deliver additional value through improved decision-making, enhanced customer experiences, new capability development, and competitive positioning that may be harder to quantify but can be far more significant for long-term success.

Changes in the Organization

Perhaps most importantly, the shift from automation to intelligence requires organizational evolution. Traditional automation replaced manual processes with automated versions of the same processes. AI enables entirely new ways of working, new roles for human employees, and new organizational capabilities.

Success in the AI era requires developing new skills, establishing new governance frameworks, and creating new partnerships between human intelligence and artificial intelligence. It requires leaders who understand both the possibilities and limitations of AI systems, and who can guide their organizations through transformation that goes far beyond simple technology adoption.

The Path Forward

Recognizing the strategic imperative for AI transformation is only the beginning—the critical question for leaders is how to translate this understanding into actionable organizational change. Many leaders find themselves caught between the urgency of competitive pressures and the complexity of AI implementation, unsure where to begin or how to build on their existing technology investments. The good news is that successful AI adoption doesn't require abandoning your current automation infrastructure or starting from scratch. Instead, it demands a strategic approach that leverages your existing foundation while systematically introducing intelligence capabilities where they can deliver the greatest impact. The organizations that will dominate tomorrow's markets are those that begin this journey today with clear vision, practical planning, and decisive action.

Starting Your Intelligence Journey

For enterprise leaders ready to move beyond traditional automation, the journey begins with understanding your current state and identifying opportunities for intelligent augmentation. This doesn't mean abandoning successful automation systems—it means identifying where intelligence can provide value that rule-based systems cannot deliver.

Begin by examining processes that currently require human judgment, creativity, or adaptation to changing conditions. Look for areas where your organization struggles with ambiguous situations, complex decision-making, or the need for personalized responses. These are the areas where AI can provide immediate value that traditional automation cannot match.

Building on Your Automation Foundation

The evolution to intelligence builds on rather than replaces your automation foundation. Your existing systems provide the data, processes, and infrastructure that AI systems need to operate effectively. The key is identifying integration points where AI can enhance automated processes with pattern recognition, content generation, or autonomous decision-making capabilities.

Consider how Traditional AI could improve your existing systems' decision-making, how Generative AI could enhance your content and communication processes, and how Agentic AI could manage complex workflows that currently require human coordination and oversight.

Preparing for the Future

The evolution from automation to intelligence is accelerating, and the competitive advantages available to early adopters are significant. However, this transformation requires careful planning, substantial learning, and thoughtful implementation. Success belongs to organizations that understand both the tremendous possibilities and the practical realities of AI adoption.

The future competitive landscape will be defined by organizations that successfully combine human intelligence with artificial intelligence, leveraging the unique strengths of both to create capabilities that neither could achieve alone. Understanding this evolution from automation to intelligence is the first step in preparing your organization for that future.

The journey from automation to intelligence represents one of the most significant business transformations in decades. Organizations that began this transition early are already seeing competitive advantages in efficiency, customer experience, and innovation capability. Those that delay risk falling behind in markets where intelligence-augmented competitors can respond faster, serve customers better, and operate more effectively.

As a leader, your role is not to become an AI expert, but to understand the strategic implications of this technology and guide your organization through intelligent adoption. The companies that will thrive in the next decade are those whose leaders recognize that intelligence isn't just the next stage of automation—it's a fundamental transformation in how businesses can operate, compete, and create value.

The question isn't whether this technology will affect your industry—it's whether your organization will lead this transformation or struggle to catch up with competitors who understood its implications and acted decisively. The time for learning and experimentation is now, while the competitive landscape is still forming and the opportunities for differentiation remain vast.

The leap from automation to intelligence is not just changing what our systems can do—it's changing what our organizations can become.

As you sit in your office reviewing quarterly reports, you might notice something remarkable: many of the processes that once required armies of analysts, clerks, and specialists now hum along quietly in the background, managed by systems that seem almost invisible. Your payroll runs without human intervention, your inventory adjusts automatically based on demand patterns, and customer inquiries get initial responses within seconds of arrival.

This is the world that traditional automation built over the past several decades—a world of incredible efficiency, precision, and speed. Yet today, we stand at the threshold of something far more profound: the evolution from automation to true intelligence. Understanding this transformation isn't just about staying current with technology trends; it's about recognizing a fundamental shift that will redefine competitive advantage in virtually every industry.

The Rule-Based Revolution

When we talk about traditional automation, we're describing systems built on explicit rules and predetermined logic. These are the digital workhorses that have transformed business operations since the 1980s—systems that follow carefully programmed instructions to execute tasks with mechanical precision.

Think about your organization's most reliable automated processes. Your enterprise resource planning (ERP) system processes purchase orders by following exact sequences: check inventory levels, verify vendor information, confirm budget approval, generate purchase orders, and update financial records. Each step follows predefined rules: if inventory falls below X units, and if the vendor is approved, and if budget Y has available funds, then execute the purchase.

This rule-based approach has been transformational in its own right. Consider the payroll system that processes thousands of employee payments every two weeks. It calculates wages based on hours worked, applies tax withholdings according to current regulations, deducts benefits contributions, and transfers funds to bank accounts—all without human intervention. The system handles complexity through exhaustive rule sets that account for overtime calculations, different tax brackets, various benefit plans, and state-specific requirements.

The Tremendous Value of Traditional Automation

The business impact of traditional automation cannot be overstated. Over the past four decades, these systems have fundamentally transformed how organizations operate, delivering value that extends far beyond simple cost savings.

Labor Cost Transformation

Traditional automation has eliminated millions of hours of manual work across industries. Bank tellers no longer manually calculate interest on every account—automated systems handle these calculations instantly for millions of customers. Manufacturing assembly lines operate with robotic precision, producing goods at speeds and consistency levels impossible for workers. Administrative tasks that once required dedicated staff—data entry, report generation, basic calculations—now happen automatically.

Speed and Consistency

What once took days now happens in seconds. A credit approval that required multiple people reviewing documents and making phone calls can now be processed automatically within minutes. Purchase requisitions that moved through paper-based approval chains for weeks now route electronically and receive approvals in hours. The speed advantage has enabled entirely new business models and customer expectations.

Always-On Operations

Perhaps most significantly, traditional automation enabled 24/7 operations without the complexity and cost of round-the-clock staffing. Online banking systems process transactions at 3 AM with the same reliability as during business hours. E-commerce platforms handle orders, process payments, and update inventory around the clock. Global operations can function across time zones without requiring human intervention for routine processes.

The Inevitable Limitations

Yet for all their remarkable achievements, traditional automation systems eventually hit fundamental limitations that no amount of additional programming can overcome. These limitations aren't failures of the technology—they're inherent constraints of rule-based systems that become apparent as business needs evolve.

The Ambiguity Challenge

Rule-based systems struggle when faced with ambiguous situations that don't fit predefined categories. A customer service chatbot programmed with scripted responses can handle "What are your hours?" or "How do I reset my password?" but fails when confronted with "I'm frustrated with your service and considering switching to a competitor—what can you do for me?" The nuanced emotional context, the implied threat, and the need for creative problem-solving exceed the capabilities of rule-based systems.

The Context Problem

Traditional automation systems process information in isolation, lacking the ability to understand broader context or relationships between seemingly unrelated data points. An inventory management system might automatically reorder products based on current stock levels and historical demand patterns, but it can't consider that a major competitor just announced a product recall, a new regulation is changing customer preferences, or a social media trend is shifting demand in unexpected directions.

The Creativity Constraint

Rule-based systems cannot generate truly novel solutions or approaches. They can optimize within predefined parameters—finding the most efficient route, the lowest cost supplier, or the optimal inventory level—but they cannot reimagine the fundamental approach to a problem. They cannot ask "What if we completely changed how we think about this process?" or "What would our customers really value that we've never offered before?"

The Adaptation Limitation

Perhaps most significantly, traditional automation systems require explicit reprogramming to handle new situations. When business requirements change, tax laws evolve, or market conditions shift, these systems need human programmers to update their rules and logic. They cannot learn from experience or adapt their behavior based on new patterns they observe.

Consider the challenges faced by traditional fraud detection systems in banking. These systems use rules like "flag any transaction over $10,000" or "alert if someone uses a card in two different countries within 24 hours." While effective for known fraud patterns, they struggle with evolving criminal techniques, generate high false positive rates, and require constant manual updating as new fraud methods emerge.

The journey from manual processes to rule-based automation has been transformative, delivering unprecedented efficiency, speed, and consistency to business operations worldwide. Yet as we've seen, traditional automation's greatest strength—its ability to execute predetermined rules with perfect reliability—has become its fundamental limitation in an increasingly complex and dynamic business environment.

The rigid boundaries of rule-based systems, their inability to handle ambiguity, understand context, or adapt to new situations, have created a ceiling that no amount of additional programming can break through. This is why the emergence of artificial intelligence represents far more than just the next incremental improvement in automation technology. As we'll explore in our next article, "The Leap to Artificial Intelligence," AI doesn't simply make rule-based systems faster or more comprehensive—it represents a complete departure from predetermined logic toward systems that can learn, adapt, and reason through problems in ways that mirror human cognitive abilities, finally breaking through the barriers that have constrained traditional automation for decades.