AI agents that ask before they act
We build autonomous systems for operations, sales, and research teams. Every irreversible action stops for a human first.
Example agent run, run · invoice-reconciliation-agent. plan: 3 steps identified. tool call: xero.list_invoices(status="unpaid"). result: 14 invoices, 3 flagged mismatched. approval: waiting for human. approved: by finance@client.com. tool call: xero.apply_credit_note(...).
Live trace. The approval gate is not a mock, it is how every write path we ship behaves.
What we build
Four families of agent. Each one owns a workflow end to end, reports what it did, and stops at the boundary where a human should decide.
- Operations agents
Reconcile records across systems that were never designed to agree, chase the exceptions that fall out, and keep the ledger and the source of truth in sync without a person re-keying anything.
- Invoice and payment reconciliation against accounting systems
- Exception queues that escalate with the full record attached
- Sales agents
Qualify inbound while it is still warm, enrich against the sources your team already trusts, book the meeting, and hand the rep a briefing rather than a lead ID.
- Inbound qualification and routing on your own criteria
- Calendar booking with a context handoff the rep can actually read
- Research agents
Monitor the sources that matter, pull evidence rather than summaries, and produce briefs where every claim carries the citation that supports it.
- Continuous source monitoring with change detection
- Cited briefs with the retrieval trace attached to each claim
- Support agents
Resolve tier-one volume against your real documentation, and when a case needs a person, escalate it with the history, the attempted fixes, and the customer context already assembled.
- Tier-one resolution grounded in your own docs, not the open web
- Escalation packets that arrive complete, not as a ticket stub
How we build
Four commitments that hold on every engagement. They are the reason our systems survive contact with a real finance team.
Approval gates on every write
Read operations run free. Anything irreversible stops for a human and presents a diff of exactly what will change before it changes. No agent of ours has ever needed permission it was not explicitly granted, because it cannot take one.
Feature-flagged integrations
Connectors ship staged and reversible behind flags. A misbehaving integration gets switched off in a config change, not ripped out and rebuilt under pressure while your team waits.
Demo mode by default
Every system we build runs end to end without a single live API key. You evaluate the whole workflow on seeded data before you connect anything of yours to it. Procurement tends to like this part.
Memory that recalls, not just stores
Vector recall over real embeddings, scoped per user, with the retrieval trace visible in the output. When an agent cites something, you can see which chunk it pulled and why that chunk scored.
- Perceiveread state
- Plandecompose
- Gatehuman decides
- Actwrite
- Observeverify
Work
Three systems in production. The technical detail in each is the part that was actually hard.
Synca
Conversation-first AI secretary
- Problem
- Founders were losing decisions inside conversations. The commitments existed, but only in threads nobody re-read, so follow-through depended on whoever happened to remember.
- What we built
- A secretary that lives in the conversation rather than beside it. It reads the thread, extracts the commitments and the context around them, and recalls the right piece at the moment it matters instead of when asked.
- The hard part
- Per-user scoped pgvector recall over chunked conversation history, with the retrieval trace surfaced in the response. The scoping is enforced at the query layer, not filtered after the fact, so one user’s embedding space is never a candidate for another user’s search.
Recall that stays relevant as history grows, because scoring runs against a user’s own corpus rather than a shared index that dilutes with every new account.
- FastAPI
- Next.js
- pgvector
- Claude API
Hosted research platform
Multi-tenant deep research
- Problem
- Deep research tooling existed as a single-user script. Making it a product meant every run needed an owner, an audit trail, and isolation from every other tenant.
- What we built
- A hosted fork with Supabase identity in front of it, per-user scoping through the whole run lifecycle, and deployment on Railway so a research job can be long-running without holding a request open.
- The hard part
- Identity threads from Supabase auth down into the research runtime itself, so a job’s source fetches, intermediate state, and final report all carry the same ownership boundary. Long-running jobs survive redeploys rather than dying with the process that started them.
A single-user research script became a multi-tenant platform without rewriting the research engine underneath it.
- GPT Researcher
- Railway
- Supabase
- PostgreSQL
AI HR recruitment platform
Screening and shortlisting
- Problem
- Screening volume forced a choice between reading every application properly and answering candidates within the week. Most teams quietly pick the second.
- What we built
- A screening system that reads applications against the role’s actual requirements, produces a structured assessment with the evidence it drew on, and shortlists with reasoning a hiring manager can argue with.
- The hard part
- Assessments are evidence-linked: every judgement points back to the span of the application that produced it. That makes a decision reviewable after the fact, which is the difference between a screening tool and a liability in a regulated hiring process.
Screening that scales with volume while every shortlist decision stays traceable to the text that justified it.
- React
- FastAPI
- PostgreSQL
- Claude API
Stack
What we reach for. No logos, no badges.
- React
- Next.js
- FastAPI
- LangChain
- Claude API
- PostgreSQL
- pgvector
- Railway
- Supabase
Engagement models
Three ways to start. The last row is the one most people are really asking about.
| Attribute | Discovery sprintScope one workflow, prove it can be agentic. | Build engagementShip the system into production. | Managed agentsWe run and improve it while you use it. |
|---|---|---|---|
| Best for | Teams with a workflow in mind and no certainty it is automatable | A validated workflow that needs to exist in production | A shipped system that needs to keep working as your tools change |
| Duration | 2 weeks | 6 to 12 weeks, scoped per workflow | Monthly, cancel with 30 days notice |
| What you get | A working prototype in demo mode, an integration map, and a build estimate | The production system, connectors, approval gates, and a runbook your team owns | Monitoring, model and prompt tuning, connector maintenance, and new capabilities as you need them |
| Approval gates | On every write path | On every write path | On every write path |
| Runs without live API keys | Yes, that is the whole point | Yes, demo mode ships alongside production | Yes, retained for staging and demos |
| What you own at the end | The prototype, the code, and the integration map. Yours whether or not you continue. | Everything. Source, prompts, evals, infrastructure config, in your repositories and your accounts. | Everything, continuously. Stopping the retainer stops our work, not your system. |
Questions
What happens to our data?
It stays in your infrastructure wherever the architecture allows it. We deploy into your cloud accounts and your databases by default. Where a model provider has to see data, we scope what is sent to the minimum the task needs, and we tell you exactly what crosses that boundary before we build it, not after.
How do you choose which model to use?
Who owns the code?
How long does this take?
What if our systems have no API?
What happens when an agent gets it wrong?
If you have a workflow that should be running itself, we should talk about it.
Or email hello@rubatt.com