What We Won't Let Our Own Software Do

Ask anyone who has watched a CRM rollout die. It very rarely dies because the software couldn't do something. It dies because the people who were supposed to feed it stopped feeding it, and six months later the data inside is wrong often enough that nobody trusts it, and once nobody trusts it nobody opens it.

There are two well-worn ways to get there. The first is friction — you ask humans to type things into fields that benefit someone other than themselves, and eventually they stop. The second is distrust — you let an AI fill those fields instead, it is confidently wrong a handful of times in front of the wrong person, and everyone quietly goes back to the spreadsheet. Same empty system, different cause.

Palanae is our attempt at the third path, and the shape of it is the reason this page exists. Instead of asking people to enter data, it structures what a business already produces — the meeting that happened, the document that got sent, the decision that got made — so that the accumulated record becomes the asset. That's where the name comes from: the Palanaeum, a library you go to in order to find what is already known.

But capture-first only works if the captured record is trustworthy, and trustworthiness is not a feature you add. It comes from what the system is prevented from doing. Everything below is a constraint we chose, and — the part that actually matters — the mechanism that makes each one impossible to violate later, including by us, on a deadline, at eleven at night.

No agent in Palanae writes directly. Ever. Every action an AI wants to take lands in a review queue as a proposal, and a human approves it or doesn't.

That's a common enough promise. What's uncommon is how it's kept. We didn't write it in a policy document and trust ourselves to honor it. The agent code is not permitted to import the service layer's write functions at all. A lint rule forbids the import. Its only available output is a row in proposals.

And the lint rule itself is covered by a test that runs in the failing direction — a test that writes code violating the rule and asserts that the linter rejects it. If someone ever loosens the rule, that test fails, and continuous integration blocks the merge.

So the guarantee doesn't rest on anyone's memory or on a reviewer catching it. A developer under deadline pressure cannot casually violate it, because the violation doesn't compile cleanly through the pipeline. That's the difference between a principle and a constraint.

There's a philosophical objection worth answering, because clients raise it: if the AI drafts the change and the human just clicks approve, is the human really deciding? Our answer is that the human's approval is the authorization; the AI is the executor — the same relationship you have with the Save button. What matters isn't who moves the bytes. It's whether a human reviewed this specific change, or knowingly pre-approved a class of changes. So autonomy is a per-action-class setting, deliberately, and the question stops being philosophical and starts being a configuration a customer owns.

Palanae is never the payroll or general-ledger system of record. Not “not yet.” Not “unless a big enough customer asks.” It's written into the architecture document as a permanent boundary.

Both look like natural next steps, and neither is. Payroll means multi-state tax filing liability, moving other people's money, bonding requirements, and an entirely different insurance posture. Being the accounting system of record means audit obligations. Those aren't features — they're a different company, with different regulators and a different risk profile.

So we integrate with whatever payroll and accounting systems a business already has, and we own the intelligence layer on top. The reason we're telling you about a boundary rather than a capability is that a firm that has never told you what it won't do hasn't thought hard enough about what it will. Scope discipline is not modesty. It's the thing that keeps a small team's work good.

Most of what you're buying when you hire a firm to build something is invisible on the day it ships. Two systems can look identical in a demo and be nothing alike eighteen months later, when one of them has quietly accumulated eleven ways to write to the same table and the other still has one.

You can't easily inspect that in advance. What you can do is look at how a firm treats the system where it has no client, no deadline pressure from outside, and nobody to impress — and see whether the discipline is real there.

That's the entire argument for this page. We took the harder path on our own product in four specific places, we can point at the mechanism enforcing each one, and none of them were free. If we build something for you, this is the standard it gets built to.