Five months of open beta: what our customers actually did with Celigo Ora

Why Celigo Ora? The history of AI in the Celigo Platform

Celigo has built AI into our platform since 2019. 

We started out in error management, using natural language processing and a lot of crunching through API data to classify, analyze, and resolve errors efficiently.

When generative AI arrived we started tinkering, putting small utilities at specific points in the product. For example, we built a natural language interface that generated a description of any flow, which our customers used quite a bit for use cases like “Tell me what this JavaScript snippet is doing.”

But then Scott Henderson, our CTO, posed a challenge. If the future of UI was chat, could we drive the platform through a chat interface? 

From there, we got to work. We’ve been API-first from the start, so we had a robust set of APIs to build on. As model capabilities improved and token windows got larger, our ambitions grew with them.

Today, Celigo Ora is a natural language interface that can do anything the platform can do. It routes what you’re trying to do to a set of specialist agents underneath: account administration, building from scratch, diagnosis, runtime analysis, and specialists in the details like our handlebars syntax, transformations, or the nuances of a particular API. You prompt, Ora makes it happen.

On its first use, Ora also builds a map or knowledge graph of the full set of integrations active in the account, then maintains that map as the account evolves. That’s what gives it the context to answer questions like: “if I make this change, what else is going to break?” 

We built permissions into Ora from the start. It doesn’t take action without the user’s explicit approval. The visual interface shows you the change before it’s made. The audit log records that you made the change, via Ora. If you’re using version control and integration lifecycle management, you can take snapshots and roll back. 

Celigo has always had a foot in the line of business and a foot in IT, and IT’s problem is constant: don’t be the bottleneck, but don’t give up so much control that the line of business does the wrong thing. The answer is the connection. If a line-of-business team only needs read access to the CRM, that’s what IT makes available, and Ora operates within those constraints. 

What we learned from Celigo Ora’s open beta

So with that, we made Ora an open beta. That means every user in every account could open it on day one.

That took some gumption. After all, they say you only get one chance to make a first impression. But we did it anyway, because we were confident in what we had built, and we valued the feedback. We wanted to learn how our customers would actually use Ora, so we could build those insights back into the product from the start.

Every Ora conversation ends with a thumbs up or thumbs down. A thumbs down automatically kicks off an engineering review on the back end, run by AI, and the output of that review is a test case Ora has to pass in the next iteration. With continuous integration and deployment behind it, we have been able to make improvements extremely quickly.

Here are three learnings that we had from the beta.

1. The most popular use case was troubleshooting, not build efficiency.

Build time matters, and we want to reduce it as much as we can. Ora is great at that. But we found that our customers’ primary use case for Ora was troubleshooting.

Far more than any other use case, users pulled up Ora when they encountered errors and wanted to know what was going on.

That’s why we built Ora to troubleshoot methodically, the way human users do:

• Read the error message.
• Perform a web search to look for that error message.
• Read the API documentation.
• Look at the audit history. Did someone change the flow recently? Has it been broken for a week, or did it only just stop working?

Retention told the same story. Users keep coming back, in spikes. Whenever customers ran into an issue, maybe an API change or a business process change, you’d see a spike of activity in the platform, along with a corresponding use of Ora.

2. Celigo Ora empowers customers to build and troubleshoot in their own languages.

Customers interact with Ora in their own languages. Japanese, Turkish, Spanish, and more. We’ve seen it in interviews with customers and elsewhere. Because the LLM under the hood knows how to speak all the languages in the world, our users simply used theirs.

We don’t have a fully localized user experience, but Ora is a great unlock for that, and it happened without us shipping anything specifically for it.

3. Celigo Ora and the UI are complementary.

The original hypothesis was whether you could drive the whole platform through chat. What the beta showed is the complementary nature of chat and a visual interface, and how they work together.

Our goal has always been to empower users to build wherever they’re getting work done. For some, that might be Celigo Ora. For others, that might be the UI. We’ve also shipped headless access: a CLI and a platform MCP server. The advantage there is that you bring your own LLM and all the other external context you may have, instead of depending on the models we’ve chosen. There’s an emerging class of users that pretty much live in their LLM all day: sitting in Claude, ChatGPT, or Gemini with all their tools connected, doing everything from there.

Even where there is headless or API-driven access to build things out, we’ve seen that those users still enjoy the comfort in being able to see what happened in the UI. My guess at how it shakes out: some development done via the CLI or platform MCP, then the user switches into the UI and uses Ora to refine it and take it the last mile. Headless for net-new builds, Ora for refinements.

And there will continue to be a class of user who is simply more comfortable in the UI, and who may not have access to their own LLM anyway. Ora embeds that capability for them.

What’s available now that Ora is generally available

As we continue to build out Ora, we’re focused on the same two core principles that we’ve built in from the beginning.

Firstly, Ora covers the complete surface area of the product. Ask it to build out the tools for your MCP server. Ask it to come up with an agent and help you write the prompt that drives it. Ask it to look at how a guardrail around an agent has been performing and help you refine that prompt further.

Secondly, the user keeps the right level of control over what happens. 

Three directions we’re pushing from here:

Shortcuts and links. Every error in the platform already has a button that feeds it into Ora. The next step is invoking Ora through a link. Say a major retail partner retires token-based authentication in favor of OAuth. Hundreds of our customers use that partner, and many aren’t following its API documentation closely enough to know. We can email them a link that opens Ora with the prompt already filled in: find all my connections to this partner, and for any not on OAuth, take me through the migration. The right action, in context, at the moment it’s needed.

Canned actions. For customers who are a bit timid about writing their own prompts, more actions that have been tried and tested.

Proactive Ora. Today Ora is passive: it waits for you to do something. We have various things in motion to make it more proactive, including running prompts on a schedule. There are workarounds for that today, and we’re making it first class.

The advice I keep giving people internally is the advice I’d give you: ask Ora. Ask it what it’s capable of, and ask it for advice. It’s usually more than you expected.

Get a demo of Celigo Ora now.