Notes from building an AI-native company

Every business we talk to has bought software that promised to save time and then quietly became someone's part-time job to operate. Our test is simple: if you have to manage it, it's software; if you only receive the completed work, it's a service. techwaves is deliberately the second thing.

Your systems feed the work in, completed outcomes come back, and nobody on your team configures, prompts, or babysits anything. The tooling is our problem — the way it should be when you hire any service provider.

Reading documents, matching bank lines, and assembling evidence is work modern models do reliably and cheaply — that part is no longer the bottleneck. The real design work is everything around it: deciding what counts as routine and what needs professional judgment, keeping an audit trail for every decision, and making the output land in a form a reviewer can approve in minutes.

That's what "AI-native" means to us — not a chatbot bolted onto old workflows, but the work rebuilt so the human hours that remain are the ones that genuinely need a human.

When a reviewer corrects something in your work — a category, a treatment, a quirk specific to your business — that correction doesn't evaporate into an email thread. It becomes a rule in your company's playbook, applied to every following period.

This is the number we manage the company by: reviewer minutes per delivered outcome, period over period. If that number falls while quality holds, the service is working. If it doesn't, we'd rather know than hide it — which is also why new engagements start in shadow mode, next to your existing process.

The last wave of technology sold businesses tools and left the work exactly where it was — on your desk. What changes now is the economics of doing the work itself: when a model can carry the routine part of a task end to end, the natural thing to sell is no longer a licence, it's the completed task. That's why the interesting new companies in this space will look like service firms from the outside — an inbox, a fee, a deliverable, a person who answers for it — and like technology companies only on the inside.

For a buyer, one habit matters more than any demo: ask who signs off, and ask what happens when the work is wrong. A software vendor points at your own staff. A service firm points at itself. We think the second answer is the honest one for this kind of work, and it's the one we give.

An agent is software that can carry a task through several steps on its own — read a document, look something up, draft an output, move to the next item — instead of waiting for a person to click after every step. That's the whole mystery. The important question is not what an agent can do, but what it is allowed to do.

Ours run with narrow, boring permissions: they read documents, match lines, assemble evidence, and draft write-ups. They cannot file, cannot execute a payment, cannot send anything to your customers, and nothing reaches your ledger except through the human-reviewed release path. Every action they take is logged — source, draft, approval, correction — and a person checks the result before it leaves. In our experience the craft is not in the model; it's in the guardrails around it.