Early access — built in the open

The back office your agents can actually run.

headless is a business platform — double-entry ledger, invoices, bills, bank reconciliation, support tickets — where every resource is reachable from a typed CLI and an MCP server, with the same permissions and the same audit trail as a human.

Get early access See how agents use it

No pricing yet, and nothing to buy — see the FAQ for exactly where this is.

agent — bash

# an agent token: one org, one role, revocable
$ export HEADLESS_TOKEN=hat_…

$ headless list invoices \
    --filter 'status=open' --filter 'total>1000'
$ headless get invoice INV-DEMO-0001
$ headless explain invoices
  fields, types, and which ones are filterable

# the same resources, as MCP tools
$ headless mcp
  list_invoices  get_invoice  create_invoice
  list_tickets   report_profit_loss  …

The problem

Running a small company means six tools that don't talk to each other — and that your agents can't touch.

Every one of them has an API. That is not the same as being operable.

Six systems, six truths

Books in one SaaS, invoicing in another, support in a third, contacts duplicated across all of them. Nothing reconciles, so you do.

Six APIs, six auth models

Each has its own tokens, its own ids, and its own idea of what a customer is. Wiring an agent across them is a bespoke integration project, every time.

All-or-nothing keys

To let an agent act, you hand it an API key with your whole account behind it. No role, no scope, no way to see afterwards what it actually did.

So the agent stays a chatbot

It can summarise a CSV you paste in. It cannot chase an unpaid invoice, reconcile a bank line, or answer a ticket — because nothing gave it a safe door.

What exists today

One platform, one tenant model, one audit trail.

This is what runs right now — it keeps a real company's books. Everything not on this list is in the roadmap, and is marked Planned there.

Accounting

Live

A double-entry ledger, not a spreadsheet with opinions.

Transactions that must balance. Lines sum to zero or the write is refused — the API asserts it, in the same database transaction.
Invoices, bills, credit notes. Editable while draft; once sent, the document is frozen and an edit is refused.
Bank accounts and statement import. Upload a statement as CSV; re-importing the same one adds nothing twice.
Reconciliation. Each statement row gets ranked match candidates; an allocation must sum exactly to the row.
Three statements. Profit & loss, balance sheet, cash flow — over a period grammar (fy2025, 2025q2, 2025-07).
Attachments. Files on invoices, bills and credit notes.

Support

Live

Tickets with a state machine that actually holds.

Real statuses. Open, pending, on hold, resolved, closed — and an illegal transition is refused, not silently applied.
Threaded comments. A public reply on a pending ticket reopens it.
Nothing is deleted. A ticket is closed; the history stays.
Same door as everything else. Tickets are a resource, so the CLI and MCP get them for free.

The platform

Live

What every module sits on, so a module never reinvents it.

Contacts are shared. One customer/vendor directory per org, read by more than one module — not copied between them.
Organisations and members. Roles (owner, admin, member, viewer), invitations, and a role that is actually enforced on writes.
Audit log. Every mutating request recorded with actor, org, action, target and status — readable in the app.
Connections. Bring your own SMTP for outbound email, or use the platform's.

Agent access

The point

The part nobody else ships.

A typed CLI. get, list, create, edit, set, delete, describe, explain, report — across every resource.
An MCP server. headless mcp exposes the same resources as MCP tools, over stdio.
Both are generated. They read the server's resource registry at startup, so a new resource shows up without a client update.
Scoped tokens. An agent token is locked to one org and one role, and revoking it takes effect on the next request.

How agents use it

Same resources. Same permissions. Same audit log.

An agent is not a special integration here — it is a principal with a role, like a person. Give it a token, and it can drive the business through the same API the dashboard uses.

headless — CLI

# Mint a token in Settings → Agents. It is shown once.
$ export HEADLESS_INSTANCE=https://app.example.com
$ export HEADLESS_ORG=acme
$ export HEADLESS_TOKEN=hat_…

# Filters are ANDed and pushed server-side.
$ headless list invoices \
    --filter 'status=open' --filter 'total>1000' -o json
{ "data": [ { "id": "INV-DEMO-0001",
             "number": "INV-DEMO-001",
             "total": "1180.00", … } ],
  "meta": { "count": 1 } }

# Money is a string on the wire. No float64 rounding,
# and total>1000 compares exactly.

$ headless explain invoices
$ headless report profit-loss --period fy2025

headless mcp — stdio

# Point any MCP client at this command.
$ HEADLESS_INSTANCE=$INSTANCE \
  HEADLESS_ORG=$ORG \
  HEADLESS_TOKEN=$TOKEN \
  headless mcp

# One tool per resource verb, derived from the
# registry at startup — no per-resource code:
  list_invoices     get_invoice
  create_invoice    list_bills
  list_tickets      create_ticket
  list_transactions get_contact
  report_profit_loss
  report_balance_sheet
  report_cash_flow
  whoami

# Every write it makes lands in the audit log,
# attributed to the agent — not to you.

Isolation, and what happens when it goes wrong

Giving an agent write access to your books is a big ask. Here's what bounds it.

Your data lives in your organisation

Every tenant table is isolated by Postgres row-level security — enforced by the database, not just by a WHERE clause somebody remembered to write. A test in CI fails the build if a new tenant table isn't isolated.

Every write is on the record

Each mutating request is logged with the actor, the org, the action, the target and the status — and an agent is recorded as an agent, so you can always tell its writes from yours. Refused writes are logged too.

Agent tokens are scoped, and revocation is instant

A token belongs to one organisation and carries one role — give an agent viewer and it cannot write at all. Only a hash of it is stored, and it is shown to you once. Revoking it is checked on the very next request: there is no cache to wait out.

The ledger defends itself

An agent cannot corrupt the books by being confused: a transaction whose lines don't sum to zero is refused, an unknown account is refused, and a document that has already been sent cannot be quietly edited.

One box, no exotic dependencies

One Go binary, Postgres, and a self-hosted identity provider — the whole production stack is a docker compose on a single VPS. Nothing here needs a cloud you can't leave.

And the honest part

This is early software with one real user's books on it. It is not certified against anything, it holds no compliance badge, and I'm not going to pretend otherwise. What isn't built is written down.

What's not built yet

The roadmap, as a list of things that do not work today.

Every row below is planned, not shipped. If it mattered to you, it is not there yet — say so on the waitlist and it moves up.

Planned

Pricing and billing

Nobody can pay for this today — a merchant of record is still being chosen, so there is no checkout at all. Pricing is genuinely undecided.

Planned

Self-serve signup

The flow is built but switched off, because there is nothing to charge for yet. Today an organisation is created for you.

Planned

Payment gateways and live bank feeds

Statements come in as CSV today. Razorpay/Stripe/Cashfree credentials can be stored, but nothing charges through them yet.

Planned

Agent memory

Per-org and per-user memory, so an agent accumulates what it learns about your books instead of rediscovering it every session.

Planned

CRM

Today the CRM module exists only to prove that a second module can read the shared contact directory. Leads and pipelines are not built.

Planned

Record-level permissions

Roles are enforced today. Finer-grained rules ("this agent may only touch this bank account") are running alongside in shadow mode — observed, not yet enforcing.

Planned

Multi-currency

The ledger is single-currency today.

Planned

More modules

Inventory, comms, e-sign and the rest are a repeatable pattern once the module registry earns it — but none of them exist. Don't buy for these.

FAQ

The questions you'd ask if we were talking.

What does it cost?

I don't know yet, and I'd rather say so than print a number I'll change. Pricing is undecided and a merchant of record is still being chosen — which means that right now nobody can pay, even if they wanted to.

The waitlist exists precisely because of that. It is how you find out when there is something to buy.

Is it open source?

No. There is no licence on the repository, so calling it open source would be a lie. If that changes, it will be because a licence file exists — not because a landing page said so.

Can I use it today?

It runs, and it keeps a real company's books — the ledger, the bank reconciliation and the reports are used in anger, not demoed. But there is no self-serve signup and nothing to pay for, so "using it today" means talking to me and having an organisation set up by hand.

Join the waitlist and say what you run. That is the fastest route in.

What can an agent actually do — and what stops it going wrong?

Anything the API exposes and its role allows: list and read every resource, and — with a writing role — create and edit transactions, invoices, bills, credit notes, bank accounts, statements and tickets, and run the reports.

What bounds it: the token is locked to one organisation and one role; a transaction that doesn't balance is refused; a sent document can't be edited; and every write it makes is in the audit log, attributed to the agent. If it misbehaves, you revoke the token and it stops on the next request.

Do I have to use agents?

No. There is a normal web dashboard, and most of the time that is what you'd use. The agent surface is what makes the dashboard's data reachable by something other than your hands — it isn't a replacement for them.

Will you migrate my data out of Zoho / Xero / QuickBooks?

There is no one-click importer, and I'm not going to claim one. Data has been brought in from a real Zoho Books ledger, but that was a mapping job done with scripts and judgement, not a button.

Is my data isolated from other customers?

Yes, and the mechanism is worth naming: every tenant table carries an organisation id and is protected by Postgres row-level security, which is forced — it applies even to the table's owner. A query that forgets to scope itself returns nothing rather than someone else's rows. A test in CI fails the build if a new tenant table is added without it.

What's the catch?

It's early, it's one person's work, and the list of things it does not do is longer than the list of things it does. Read the roadmap — it is written as a list of gaps on purpose.

Early access

Tell me what you run.

There is nothing to buy and nothing to log into yet. Leave an email and I'll tell you when there is — and what you write below genuinely shapes what gets built next.

One email, when there's something worth an email. No newsletter, no drip sequence, no sharing it with anyone.