Building Faster Horses — Using an Old Mind to Build the Future

I remember the ChatGPT moment.

I think one of the first prompts I gave it was to write a poem, and I don't know why exactly, but having been exposed to the structure and logic of how computing systems work, how software output is delivered — writing a poem felt like the ultimate test to prove this technology is totally different.

And oh boy, is it different.

I got my poem. But after that moment I started this race of figuring out how I can use this on a day-to-day basis in my businesses. I was really excited about getting my hands on the APIs, really got a bit stuck with the fact that, if you think about it, the first thing we struggled with was that the answers were unstructured. Most of our business systems at the time required structured data to handle anything, so basically if you wanted to process anything you would need some sort of JSON. And I remember using JSON structures in the output, just telling the model "output as JSON," but it wasn't very reliable — a lot of the times you wouldn't get clean output.

The Evolution I Lived Through

And then came LangChain.

LangChain launched in October 2022 as Harrison Chase's open source side project and became the de facto framework for wiring LLM calls together. In my mind, LangChain — or any orchestration tool at that time — was a big improvement. I remember using it for publishing product websites, translation, creating product descriptions for my e-commerce business. It let you chain operations: take output from one call, feed it into the next, build something resembling a workflow.

Then came GPTs in November 2023 — OpenAI's custom versions of ChatGPT. As I saw them at the time, GPTs were basically specialized packages. You'd take ChatGPT, stuff it with specific instructions and knowledge, and get something purpose-built. And once you had a few of these GPTs, you quickly realized you needed to connect them together — one GPT's output becoming the input for the next one.

And then we got agents with skills and tool use, which quite frankly were way better at handling stuff. And then the reasoning models arrived — and this is where things got really interesting. Because now you had an agent that could understand what tools were available, understand the context, understand what the required output was, and choose which tools to use.

And I remember thinking: if I have skills, and I have reasoning, and the agent understands context and can switch between tools — why would I need multiple agents? Unless I need some sort of asynchronous process, some async orchestration, why would I fragment the intelligence?

The Orchestration Trap

But this is where the whole industry went. The next logical step, it seemed, was orchestration — get a bunch of agents working together, coordinating, mimicking how organizations work. You can see it in products like Paperclip, which launched in March 2026 and hit 30,000 GitHub stars in three weeks, literally simulating corporate hierarchies with CEO agents hiring manager agents hiring worker agents. You can see it in LangGraph, which LangChain built in 2024 specifically for stateful agent orchestration. CrewAI, AutoGen — everyone is building the same thing: ways to make agents work together in structured processes.

And I have this feeling — I don't know, I have this feeling that this is not the path forward.

I think it's the human-like limitation of what we know an organization looks like. So you get a bunch of people, they get very specialized, you get relationships between them, you get a hierarchy — this guy has to do what that guy tells him but doesn't have to listen to the level below — and you get business processes. And I think it's so ingrained in our heads that an organization should be a selective bunch of people, processes, and procedures all coming together to make money for shareholders and serve customer needs.

But I don't think it's the right approach. I think it's our old mind failing to see what the future organization should look like.

It's that Henry Ford moment. The famous quote attributed to Ford — "If I had asked people what they wanted, they would have said faster horses" — turns out he probably never actually said it. The earliest trace of this quote dates to a 1999 cruise ship magazine, and it doesn't appear anywhere in Ford's authenticated quotations or autobiography. But the irony is beautiful: even the quote about not copying old paradigms is itself a copied, unverified old paradigm.

And that's exactly what's happening with agent orchestration. We're building faster horses. Bigger carriages. We're taking the organizational chart — a thing we invented because humans have limited bandwidth, need specialization, require hierarchies to coordinate — and we're imposing it on technology that doesn't have those limitations.

Why I Believe This

Look, every time you want to orchestrate a business process, you get decision blocks. If this, then that agent handles it. If not, the other agent does. And every time you get a decision block, you get a yes/no branch, and every branch doubles the complexity. So you very rapidly get to almost infinite decision trees.

I've been here before. I built chatbots years ago using regular expressions to detect user intent, and every time you detected an intent you'd give the user a choice — do you want this or that? — which became a decision block, and if the user chose one path, you'd get more branches. It was the classic if-this-then-that architecture, and the use cases grew so large that navigating the decision tree became very slow and painful for the software, with poor results for customers. I'll give you that — I never saw a chatbot that truly worked well.

And now, with multi-agent orchestration, we're doing the same thing with better technology. You get specialized agents, you connect them with business processes, and you're basically building a sophisticated chatbot architecture on steroids. The decision blocks are the same. The complexity explosion is the same. The fundamental limitation is the same.

The data backs this up too. According to Gartner, more than 40% of agentic AI projects could be cancelled by 2027 due to unanticipated cost and complexity of scaling. Deloitte's 2025 survey found that while 80% of organizations consider themselves mature with basic automation, only 28% feel the same about AI agent efforts. And only 12% expect returns within three years. The orchestration approach, the thing everyone's excited about, is already showing signs of being too complex to manage.

What I Think the Future Looks Like

I believe, and I admit I don't know how to do this yet, that maybe the correct approach is through agent autonomy. And what I mean by that is building the system in such a way that an agent understands an objective, understands what you want to accomplish, and then instead of building business processes and logic and decision trees — you build a very good process of self-improvement.

At the end of the day, I think it all comes down to learning.

Here's the framework as I see it: you have an objective, and you have a very good and objective way to measure the outcome, and you can calculate the difference between desired and actual, and then you iterate to make that gap smaller. It boils down to a very good self-improvement loop.

The Measurement Problem (This Is Where It Gets Hard)

Now, here's the thing — and this is where I'll be honest, this is where I got stuck.

We humans invented beautiful systems for measurement. Numbers. We have this convention about numeral numbers, we know 7 is greater than 5, and we know exactly by how much. If my goal is 7 and I get 5, I can clearly say the gap is 2 and then tweak the system. This is more or less how training neural networks works.

But when you move to the messy reality of business — serving a customer need, writing a good blog post, handling an objection in a sales conversation — it's not as simple as comparing two numbers. Let's say you want to write a blog post, and the desired outcome is "a good article." It's very hard to define what "good" means. You need to somehow convert it into boolean evaluations — true or false — so you can measure. The article needs to be between 500 and 600 words? True or false. It covers the three key topics? True or false. You can have many of these evaluation criteria, but at the end of the day you need to structure the measurable outcomes into something resembling a series of testable statements to really understand the gap.

And the self-improvement part — that's the biggest piece yet to come. Think about how an agent can improve. We could give it more tools, right? More skills. But once you give it a fixed set, you limit it. So I started thinking: why should I give the agent tools? Why shouldn't the agent just create the tools itself?

And for that to work, the agent needs two things: unlimited access to data (internet, databases, domain knowledge), and unlimited access to power (the ability to build tools, spin up services, execute code, call APIs). With unlimited data and unlimited power, the ability to self-improve should be — in theory — unlimited.

And coming to think about it, it's so scary. Yes, a lot of limitations will need to be in place. You don't want to achieve your outcome by any means necessary. Thank you, Terminator.

Where I Tested This (And What Happened)

I kind of got stuck on the customer-need measurement problem because, believe me, measuring whether you truly served a need is trickier than it seems. You might think "if people buy it, you served a need" — but people buy a lot of things that don't actually serve them. When you factor human nature into things, they get very complex very fast.

So I went to the next best thing: money. Everyone's organization exists to make money, and money simplifies the evaluation because it's numerical. You have a target, you can see what you have now, the gap is obvious.

So I built a trading agent. I got access to a trading API, gave the agent $200, gave it an objective to double the money in one month — unreasonable, I know, but this was all about testing the framework. I didn't give it any tools at all. I gave it four autonomous actions to deploy that $200.

And the first thing it did was buy Bitcoin and Ethereum.

I didn't tell it to do that. This was its own judgment call about the best way to fulfill the objective. Whether it was the smartest approach, I don't know, but this is how the agent decided it could close the gap between $200 and $400.

Now I'm building the evaluation part — which is not the hardest piece — and then I'll focus on the self-improvement system. I don't know exactly how I'm going to build that, but that's the experiment.

The Bigger Picture

So here's what I think the industry gets wrong, and I might be very blindfolded to a lot of things going on out there:

I don't think orchestration — orchestrating a bunch of agents in a structured way to mimic a business process — is going to be the way we build the next great company. I think it lies in agent autonomy. Specifically, I think a successful organization will turn into some sort of agentic ecosystem with a very well-defined input and expected output, most likely related to delivering value to a customer.

And inside that ecosystem, you need two systems working in sync:

An evaluation system that constantly measures current output versus desired output.

A self-improvement system with access to unlimited resources — data and power — that works to decrease the gap.

I don't think this will be general intelligence. I see it happening in limited domains, in the bounded context of specific businesses. A domain-specific agentic ecosystem, not a general-purpose one. That's not AGI. That's something else — something more practical, more constrained, and honestly more useful.

I'm still going forward with my insurance sales agent — it should work in a similar way, but it's far more complex than the trading experiment. This is why I started with the broker first, to wrap my head around the concept in a simpler domain. But definitely I'll move forward with both experiments and see how things progress.

The thing is, I don't know if I'm right. But when I look at the whole orchestration wave, something in my gut tells me we're building carriages when we should be inventing the engine. And the only way to find out is to run the experiment.

Let's see.

Building from Cluj-Napoca, Romania