Company

Built inside a support queue, not next to one.

Cura started in a working support queue, because the person building it was the one the cases belonged to.

At a glance

Based in London, UK
Measured on 16 live cases before it was called a product
Read-only by default on every package
A person reviews every draft unless you switch auto-reply on

Why we exist

The hard part isn't writing the reply.

Most support automation assumes the reply is the hard part. Spend a week in a real L1 queue and you'll see it isn't. The hard part is everything before it: reading the thread, working out who actually owes the next message, digging through notes for a handover that never happened, and finding the three past cases where someone already answered this exact question.

That work is slow, nobody sees it, and it's where things get missed. It's also what a well-built agent is genuinely good at, as long as it cites what it found and leaves the judgement to a person. So that's what Cura does, and on purpose, that's all it does.

The first version was measured on live cases in a real queue, with every mistake written down and dated. That log is still how the product improves, and it's why nothing on this site claims the agent is always right.

Where it came from

Seven days, sixteen live cases

The pilot that became Cura ran on a working enterprise support queue. It produced 21 drafts across 16 cases, logged every mistake, and not one reply reached a customer before a person had read it.

Read the case study

Principles

How we think about the work.

The agent prepares. A person judges.

Review is the default on every package, and auto-reply only fires on rules you set. We'd rather make a smaller promise we can keep than a bigger one that needs a footnote.

Every claim names its source.

A case number, a ticket, a page that actually loaded. If a document didn't load, the draft doesn't cite it. Auditable beats confident.

Better retrieval beats better writing.

Every real gain in the pilot came from finding something the agent had missed: phrase search over emails, escalation records on child cases, internal docs. None came from nicer prose.

We write down every mistake.

Dated, with the reasoning behind it. If a vendor can't show you their failure log, they haven't kept one.

Read-only until you say otherwise.

Cura holds credentials that could write to your systems, and it doesn't use them. We keep access to the smallest scope that works.

See it for yourself

The easiest way to judge all this is to watch it work on a live case.

Book a demo

Security and data

Answers for your security team, before they ask.

We answer security and data-protection questions on request. Data residency and retention are agreed per contract, and we'll put them in writing.

Read-only by default. No create, update, close or comment in your CRM, Jira or Confluence.
Your data is never used for training. Not by us, and not by a model provider.
Scoped credentials for each integration, limited to the queues and doc spaces you name.
Every retrieval is logged, so you can see what was read and when.
SSO and audit log export on Enterprise and Bespoke.
Hosted by us, or fully on-prem. Bespoke and Enterprise can run entirely inside your environment on your own Anthropic license.
No send path unless you turn one on, and every auto-reply is logged with the rules it met.

Who we are

Small, on purpose.

You'll talk to the person building it.

Julijus Streckis

Founder · London, UK

Six years in enterprise software implementation and technical support, across financial services, risk and legal tech. The work behind Cura is the work he does every day: onboarding clients onto cloud platforms, setting up identity and SSO, owning root-cause analysis on critical incidents, and writing the playbooks that stop the same case being solved twice.

Working with us

Cura came out of a real queue and was tested on real cases before it had a name.
Every mistake is written down and dated, and that log is how the product improves.
You deal directly with the person who builds and maintains your agents.

Roadmap

Where we're going.

Drafts in Teams and Slack

The last manual step. Reviewers should be able to approve or reject in the channel where the case is already being discussed.

In progress

More cases at once, without swamping reviewers

Retrieval already runs in parallel. Raising throughput only helps if review stays quick, so we're planning the two together.

Later

New domains, honestly scoped

Each new support domain needs its own index and pattern library. We'd rather say "not yet" than ship a ranker that can't see the terms that matter.

Get in touch

Questions, a security review, or a demo on our sandbox all go to the same inbox: [email protected]

Book a demo

Working here

No open roles right now. But if you've run a front-line queue and have opinions on why automation usually fails there, write to us anyway.