Nicole Ginosar
The question comes up again and again: should we build our own agent instead of buying one? And it almost always arrives with the same reasoning attached, the reasoning that sounds airtight: we know our operation better than any vendor, so we should encode that knowledge ourselves. The premise is right. The conclusion usually isn't. The gap between the two is the whole buy-vs-buy decision.
Here's the thing that reasoning rests on: creating the knowledge. Writing down the rules, capturing how the operation runs, teaching a system what a good decision looks like. And it's not wrong that you could do it. You could. Anyone can now. That's exactly the problem.
Knowledge creation has become the easy part. It used to be the moat. Getting your operational judgment out of people's heads and into a system was slow, expensive work, so if you'd done it, you were ahead. That advantage is largely gone. Capturing years of rules and domain knowledge is now something a small team can do in a quarter. So if your buy-vs-build case rests on "we can encode what we know," you've won an argument about the cheap part and skipped the expensive one.
What is the hard part of building your own AI agent?
The expensive part is everything that happens after the knowledge exists. And it's expensive precisely because it's unintuitive. Three faces of it, all of which look easy from the outside and none of which are.
Conflict management. The moment you have more than a handful of rules, they start to contradict each other. One rule says expedite when a key account is at risk. Another says hold shipments when margin drops below a line. A situation hits both. Which wins? Multiply that by hundreds of rules accumulated over years by different people, and "just add another rule" quietly becomes a system nobody can reason about. Resolving conflicts cleanly, and knowing which rule should win and why, is a hard systems problem that has nothing to do with knowing your business. You can know your operation cold and still build a rulebase that fights itself.
Self-healing. The world moves. A supplier changes behavior, a format drifts, an assumption that was true last year silently goes false. A system built by hand doesn't notice. It keeps applying the old knowledge with full confidence and produces wrong answers that look exactly like right ones. Building a system that detects when its own knowledge has become stale, flags when its knowledge no longer matches reality, and corrects instead of drifting is deeply non-intuitive. Almost no in-house version gets there. They ship the part that works on day one and never build the part that keeps it working on day two hundred.
The curation bottleneck. Here's the trap that catches the teams who do everything else right. If a human has to review, reconcile, and approve every piece of knowledge the system uses, that human becomes the constraint on the entire system. Knowledge creation scaled; your one curator did not. The thing you built to give you leverage now runs at the speed of the person maintaining it, and that person is drowning. It isn't a bug you can patch. It's the shape of the whole approach.
All of this matters more than it used to because the system doesn't just advise anymore. It acts. A contradictory rule or stale assumption used to produce a bad report or a recommendation someone could question before acting. Now it expedites an order, reroutes supply, reprioritizes inventory, or changes a customer commitment. The machinery behind the knowledge suddenly matters much more than the knowledge itself.
Why the machinery, not the knowledge, is the product
So the honest buy-vs-build question isn't "can we encode our knowledge." You can. It's "can we build and staff the machinery that keeps that knowledge from turning into a contradictory, stale, bottlenecked mess?" That machinery—conflict resolution, drift detection, self-healing, and curation that doesn't depend on one hero—is the actual product. It's also the part no demo ever shows you, which is exactly why it's the part every build-it-ourselves plan underestimates.
There are real cases where building is the right answer.
If your operational judgment is genuinely your edge, if how you decide is proprietary and central to how you win, you may want to own it end to end rather than hand it to a vendor's model of the world. And bought systems carry real lock-in: the knowledge you feed them lives in their frame, and getting it back out later isn't free. Those costs are true and worth naming.
The point isn't that building is always wrong. It's that the reason to build should never be "creating the knowledge is the hard part," because that part isn't hard anymore.
How to decide whether to build or buy
If you're weighing this right now, don't test yourself on whether you can capture what you know. Assume you can. Ask the harder question instead: a year from now, when the rules contradict each other, the world has drifted, and one person is trying to keep it all straight, who's building the system that heals itself?
If the answer is "we'll figure that out later," you've probably already answered the build-vs-buy question.
Nicole Ginosar is Head of Product at Emerix, where she works on how autonomous workflows get built, evaluated, and kept accurate in production. Before Emerix she led data engineering and analytics at At-Bay and spent time at Google and Taboola. She is also the co-founder of Data Queens, Israel's first community for women in data.