AI at AXIONX
Agents that do the work, not just the chat.
A small business loses money in the gaps: the call nobody picked up, the enquiry nobody followed up, the same half hour of copying between two tools every single day. We build AI agents that close those gaps, and we run them ourselves before we sell them to anybody.
What we are building
Five systems, all running in production on our own servers today. The first two are the ones we are turning into products for the small businesses we already build websites for.
Voice agent that answers the phone
Picks up, listens with its own voice detection, transcribes, works out what was asked and answers in about two seconds. It is not a phone tree: the same agent can look something up, read the inbox, query a database or hand a real task to a build runtime and report back when it is done.
Outreach agent that finds customers
Pulls businesses from public sources, visits each site and measures it first-hand, finds a contact address on their own pages, then writes one short email per business that may only cite problems it actually measured. It watches the inbox so a reply stops the sequence and an opt-out is permanent.
Application agent
An autonomous pipeline that collects openings from many sources, scores each one against a profile, tailors the documents, applies, and tracks every outcome, with a mobile app on top of it. It has run unattended for months and is the system most of our agent tooling was proven on.
Knowledge assistant over your own documents
Answers from the business’s own files and records, with retrieval over its data, and says plainly when it does not know rather than inventing an answer. New questions it cannot answer get queued for a human to fill in, so the thing gets better by being used.
Workflow automation
The repetitive chain between tools: a form becomes a record becomes a document becomes a notification. We build these as ordinary services with an agent only where judgement is actually needed, which keeps them cheap to run and easy to debug.
How it is built
- Next.js and React for every interface, server-rendered and fast on Indian mobile connections
- Python services behind an HTTP API, one job each, deployed as containers
- Postgres and SQLite, chosen per service rather than by habit
- Docker Compose on our own servers, so nothing depends on a managed platform we cannot inspect
- Self-hosted mail with SPF, DKIM and DMARC for anything the agents send
- Our own measurement before any claim: load time, page weight, HTTPS, mobile viewport
The agent loop
- PlanThe agent reads the task and decides the steps. This is the part that needs a model that can actually reason, and it is where we use Claude.
- ActIt calls tools: fetch a page, run a query, write a file, send a mail, start a build. Every tool is ordinary code we can test on its own.
- VerifyIt checks its own work against something external, a HTTP status, a test run, a row in a database, before reporting done.
- ReportIt writes back in plain language, and everything it did is in an append-only log we can read later.
Where we are
We build and ship websites and web apps for paying clients today. Alongside that we run our own AI agents in production on our own servers, and we are productising them for the same customers now, starting with a private beta.
Shipping
Websites, online stores and web apps for paying clients, scoped and quoted upfront. That work funds the agent development and keeps us close to the businesses the agents are for.
In production, internally
The voice agent, the outreach agent and the application agent run every day on our own infrastructure. We are our own first user, which is why the rough edges get found.
Next
Moving the agent runtime onto the Claude API so customers can use it directly, with per-customer limits, an evaluation harness for every prompt we ship, and a private beta for the voice and outreach agents.
Honest limits
Things we will tell you before you ask, because finding out later is worse: an agent that sends mail on your behalf needs a warm-up period and a daily cap, or your domain gets filtered. A voice agent cannot take a payment or make a booking on a system that has no API. A retrieval assistant is only as good as the documents you give it. And anything with judgement in it needs a human reviewing the first few weeks of output. We build for those facts rather than around them.
Frequently asked questions
Which model do you use, and why?
Claude does the planning and the code-writing in our agent runtime, because those are the steps where a weaker model quietly produces work you then have to redo. High-volume, low-judgement steps such as transcription or short classification go to smaller, cheaper models. Routing by the difficulty of the step rather than using one model everywhere is what makes the economics work at our size.
Do you train models on our data?
No. Your content is used to answer your questions and nothing else. We do not train or fine-tune any model on client data, and we will tell you exactly which providers process what before you sign anything. See our privacy policy for the current list.
Can we run it on our own infrastructure?
Usually yes. Everything we build is containers, a database and an HTTP API, so it can run on your server or ours. Where a hosted model is involved we will say so, because that part leaves your machine by definition.
What does an agent cost to run?
Far less than people expect, because most steps do not need the expensive model. We quote a build price and a realistic monthly running cost separately, and we would rather talk you out of an agent than sell you one for a job a scheduled script does better.
Tell us what keeps falling through
Describe the gap, the missed calls, the follow-ups nobody gets to, the half hour you lose every day, and we will tell you whether an agent is the right answer and what it would cost to run. If a scheduled script would do it better, we will say that instead.
Start a conversation