Agents all the way down: How building Celigo Ora rebuilt everything else

Today, Ora is generally available as the way to work with Celigo. For the past fourteen months, it’s been built almost entirely by other AI agents, not people, a bet we made before there was any proof it would work. Humans still review outcomes and approve every merge, and Ora already runs in production for thousands of companies.

In practice, Ora is the AI built into Celigo, and the simplest way to describe it is also the most ambitious: anything you can do in the Celigo UI, you can hand to Ora. It builds the flows and the connections, writes the field mappings and the JavaScript, diagnoses last night’s failures, manages users, tokens, and environments, and answers questions about anything in your account. It is a new way of working with the entire platform through natural conversation, where every change is staged for your approval before it touches your account. That arrangement, with agents doing the work and people approving it, is how we built Ora itself.

Why trust an AI agent with mission-critical integrations?

Celigo integrations are mission-critical infrastructure (order-to-cash, inventory, fulfillment, billing) running at massive scale for thousands of companies across thousands of use cases. In this category of software, a failure that goes unnoticed costs real revenue, and our engineering team has operated it long enough that nobody here is casual about the word “production.” Inviting an AI into that work means asking people to extend trust in the place where the cost of misplaced trust is highest.

That kind of trust can’t be bolted on by a team that has only read about agents. The systems that make an AI safe enough for this job (staged changes, dry-run validation, judged output, full auditability) are designed by engineers who work this way themselves, who know from daily experience where trust breaks down, and who build the guardrail before a customer ever reaches it. Ora itself is the proof. It is production software serving those same customers, and since its first commit in June 2025 it has been built almost entirely by agents under human direction, with humans reviewing outcomes and performing every merge. That is the same arrangement we ship to you, in which people set intent, agents do the work, and people approve the result.

How we rebuilt our engineering process around frontier AI models

When we started in mid-2025, the frontier models could write competent code in small pieces but couldn’t be trusted with much more, so humans reviewed every line the agents wrote. The frontier moved quickly, though. Every few months a new generation of models arrived that could hold more context, plan further ahead, and recover from its own mistakes, and every release let us hand the agents something bigger: first a function, then a feature, then a migration, and eventually whole projects running in parallel.

But a new model only delivered its gains when everything around it kept up. An agent is only as good as the context it can find, the conventions it can follow, and the feedback that catches its mistakes before a human has to, and all of that is ours to build, not the model’s. So each time the models leveled up, we rebuilt our engineering system to match:

We rewrote our documentation for a reader that pays by the token. Our internal docs are organized so an agent handed a bug report can load only the context that matters. A routing table maps symptoms to the one or two documents that cover that subsystem. We optimize documentation for “tokens-to-competence” the way we used to optimize onboarding for new hires. New engineers, it turns out, love it too.

We turned tribal knowledge into standing rules. The unwritten conventions a senior engineer carries in their head became explicit, always-loaded invariants: how to handle errors, what never to log, which safety barriers must never be bypassed. Agents follow written rules with a consistency humans never achieved.

We rebuilt testing around judgment, not just correctness. Ora’s test suite has grown to tens of thousands of tests. Thousands of these are evaluations: tests where one AI grades another AI’s work against intent, not just against expected output. When your engineers are agents, “does it compile” is table stakes; “did it do what the user meant” is the bar.

We kept humans where they add the most value. Humans give direction up front and review at the boundary, and every change still lands through a pull request. What changed is what a “review” is: it used to mean proofreading, now it means judging, the same shift a senior engineer makes when they stop line-editing juniors and start setting standards.

What happened to our engineering velocity?

The whole story is written in our git history. For the first six months the commit log looks like any small team’s, because humans were still reading every agent-written line while we built that scaffolding. The limit in those months was never how fast agents could write, it was how fast we could review. In January 2026 we changed the review model: humans judging outcomes instead of reading lines, with agents reviewing each others’ work before a person ever looked. Output nearly quadrupled in a single month, with the same handful of people.

Within weeks, agents were shipping commits under their own names. By spring, every engineer was directing several agents at once while agents swept our production logs for regressions and audited each platform release. Over the past six months we have run at nearly 700 percent of our starting pace. When Celigo Ora launched in beta in March 2026, we shipped more commits that month than our entire first six months combined.

The curve wasn’t one breakthrough. Each generation of models let us trust agents with more, and each piece of the process we rebuilt turned that trust into speed. Velocity compounded because both kept improving at once.

None of it required an army, and that is the point. When agents do the writing, the leverage shifts entirely to people who know their domain inside and out: engineers who can specify precisely, spot a wrong answer instantly, and judge outcomes with the taste that comes from years of operating this platform. A handful of people with deep context now carry a codebase that would traditionally take an organization. They also keep it healthy as they go, because agents take on the refactors, migrations, and cleanup that human teams perpetually defer. Some months the codebase gets smaller while the product gets bigger.

How does Ora actually work?

The part I find genuinely elegant is that Ora, the product, is the same mechanism we just described, packaged for your Celigo account instead of our codebase.

When you work with Ora, you describe intent in natural language. Behind that conversation, dozens of specialized agents plan the work, build the configuration, test it against live sample data, and have their output judged before it ever reaches you. Together they wield hundreds of tools across every corner of the platform, grounded in a live knowledge graph of your account’s integrations, flows, connections, and dependencies. When the work is ready, the change arrives as a staged approval card: you see exactly what will change, and nothing touches your account until you accept it. That is a pull request review, translated for integration work. If you want to see the plan before anything happens, Ora’s planning mode is our design review. If you want Ora to permanently follow your team’s conventions (naming standards, environments it must never touch), rules files are the same standing guidance we use to govern our own agents.

Every trust mechanism in Ora exists because we needed it ourselves first: the staged approvals, the planning mode, the standing rules, the judged output all earned their place across fourteen months of agents doing real work under human authority. That is what agentic AI production trust looks like in practice: earned across many months of real use, not just in a press release.

How is this way of working spreading across Celigo?

What started as the Ora team’s way of working is becoming Celigo’s. The patterns this team proved out (documentation organized for agents, tribal knowledge written down as standing rules, tests that judge intent, agents watching production and auditing releases, humans directing and judging rather than typing) are spreading through every engineering team and every repository. The shift doesn’t stop at engineering, either: the same operating model (describe intent, direct agents, review outcomes) is becoming how people across Celigo work, from support to product to marketing. This post, fittingly, started life as a brief to an agent.

If I had to compress the lesson for other executives into one sentence, it would be this: adopting AI is not a tooling decision but an organizational redesign, and the companies that redesign will outrun the ones that install a coding assistant and declare victory.

The beta tag comes off, and the journey continues

Starting September 2026, after a six-month beta spanning more than 16,800 real conversations, Ora loses the beta label and becomes what we built it to be from the first commit: the primary way to work with Celigo. The UI isn’t going anywhere; it is evolving into what our own workflow suggests it should be: the place where you review, approve, and observe while the agent does the building.

We didn’t stumble into this way of working, and we didn’t run it as an experiment. We knew agents would build Ora before a line of it existed, and what fourteen months added is the measurement of what that decision is worth when you commit to it all the way down and rebuild everything around it. We redesigned how we work, and now that way of working is yours.

Starting September 2026, Ora is now generally available to all customers, right inside the platform. Read the announcement. 

Sign up for a 30-day free trial to try the thing we can’t stop using. Need help getting started? Our 5-minute Ora walkthrough takes you through the experience step by step.