Pulse reads the rule you approved, verifies the facts in your systems — CRM, ERP, accounting, helpdesk — and takes the case to completion. Above the authority line it prepares a draft and waits for a signature. Every step leaves a record; it exists because the work was done, not as extra work. We run our own e-commerce store, Squated.one on it.
We're picking three companies and building each a working prototype — up to CZK 80,000 worth of work.
What it is
A digital colleague for repetitive admin. Not a chatbot.
How it knows what to do
From a rule that is a readable document — you write it together and approve it.
What it must not do
Nothing beyond its authority. Money, law, people and data stay with a human.
You have a refund procedure and it's correct. It's just that between the rule and its execution stands a person: open three systems, gather the facts, compare them against the procedure, check the limit, do it, record it. Only one of those six steps needs judgement. And alongside the written procedure there's a second layer of rules that exists nowhere — the gotchas known only to whoever does the work. Those are what decide the outcome, and they leave when that person does.
What triggers it | A customer asks for their money back |
|---|---|
What gets verified | The order exists · the payment arrived · no credit note has been issued |
What gets done | Issue a credit note · reply to the customer quoting its number |
What to watch out for | After a reply, the thread reopens and looks like a new case. The invoiced amount may not be the amount actually paid. |
What counts as done | The credit note is in accounting and the reply has gone out |
Who decides | Up to CZK 500 on its own · up to CZK 5,000 draft for approval · above CZK 5,000 a human |
```18:42:04 email: "I paid twice, I want CZK 340 back."
18:42:04 rule refund_request, version 4, read
18:42:06 store: order 4471, two payments of CZK 340
18:42:07 bank: both payments received
18:42:08 accounting: no credit note exists
18:42:08 tier: CZK 340 → autonomous
18:42:31 credit note CN-2026-118 issued
18:42:33 sent to customer
18:42:33 recorded: who, when, under which version of the rule
`Twenty-nine seconds and nobody touched it. "Done" here means you can read it in the target system, not that someone filed a report saying so.
Work starts wherever the company talks — in email, on the support desk, in Slack or Teams. Pulse joins those channels as a colleague. Nobody has to learn to visit yet another system.
It reads the facts where they actually live: CRM, ERP, accounting, the store, the helpdesk, the CMS. Integration runs over an API or MCP — we don't introduce a new tool, we extend the one your team already knows.
The input is a thread, not a form. The task is derived from the whole conversation — the follow-up questions, the forwards, the changes along the way. All that's asked of a person is the decision.
A case is a record, not a precondition. Work doesn't start with someone opening a ticket. The ticket is the trace it leaves behind.
Authority follows the rule and who is speaking — not which channel the message came from.
You already have a signing authority policy. Today it holds because people are disciplined — someone has to remember that this one now goes to the managing director. Here the system holds it, and it can't be bypassed by mistake or under pressure.
What decides where a piece of work belongs isn't how important it is. It's a single question: what happens if it goes wrong?
Runs on its own — you fix the mistake and nobody outside the company notices.
Draft for approval — you could fix the mistake too, but the customer would have seen it. So the agent prepares everything and a human just presses the button.
A human decides — the mistake can't be taken back: money, law, people, deleting data.
You set the boundaries and they hold regardless of what arrives at the input. If an email from a customer or a supplier asks for more authority, the agent doesn't get it.
For regulated operations this is the point: the agent doesn't decide what requires approval. It just prepares the case so completely that the decision takes you a minute instead of an hour.
When someone rewrites a draft — right there in the thread where it's running — that correction is stored as a dated rule and applies to every case that follows. It doesn't stay an instruction that gets lost in chat.
The agent has no memory between days: what isn't written down, it won't know tomorrow. So each thing gets explained once. What one person holds in their head today is tomorrow a rule that also applies to whoever joins a year from now — and the more of them are written down, the fewer cases wait on a human.
The first month will cost you time. Someone has to read the drafts and correct them. That's the investment: without it the agent would know generic procedures, not yours.
After that you see three numbers each week: how many cases ran without intervention, how many someone rewrote, and how many ended up with a human. Those are what you move the authority limits by. Moving them on a hunch is a gamble.
Admin automation doesn't stop at one process. The structure is always the same — read the rule, verify the facts, act up to the authority, record it. Only the content changes.
Round-the-clock operations. The cheapest capacity is the kind that doesn't need shifts. First response within the SLA at any hour, different deadlines for different customers, proof that the SLA was met. At night a person is woken only for what genuinely needs them — and with the case already prepared.
Accounting and finance. Chasing missing documents for payments. Checking invoices against orders and flagging discrepancies. A cash-flow outlook that speaks up on its own when a shortfall is coming. Overdue reminders for approval. A change to a supplier's bank details always to a human — it's a one-way door and a classic fraud target.
Customer support, L1 and L2. Order status from live data. Refunds and credit notes by threshold. Whatever belongs to a human is escalated with full context — not as an empty ticket. A signal when the same complaint starts repeating.
Reporting across roles. Metrics that link to the source instead of numbers retyped by hand. Monitoring that stays silent while everything is fine. An ad-hoc analysis of a question asked in conversation — what refunds cost us on one product line last year — with the source attached instead of an estimate. A pack for the weekly meeting: what's stuck and where a decision is being waited on.
Yes, when the process repeats every week, it's done by someone you pay for their judgement, you can say where "done" is visible, and someone will approve the rules.
No, when you're looking for a website chatbot, the process is done differently every week and nobody knows why, or nobody has time for corrections in the first month.
It isn't a project with a completion date. The rules are part of operations — each one needs a person who approves and reviews it. Without that it ages like any internal policy, and the operation will dutifully keep doing what the policy said last year.
Operations, development and part of support for our store Squared.one are handled by Lumi — the first Pulse in real production, not in a slide deck. It takes smaller fixes as far as a proposed change and turns a monitoring signal into a recorded case. The architecture comes out of a real company's problems.
A human ships to production. Always.
You pick one process — repetitive, well-bounded, currently paid for with qualified people's time.
We write the rule with whoever does that process today — into the shape of the table above. Hours of work, not a quarter.
We connect read access to the data. Reading changes nothing and is audited.
We run it in draft mode. Nothing goes out without a signature, so the first week carries no risk.
After a few weeks you decide from the numbers what can go out on its own.
How is this different from the AI assistant we already have?
An assistant answers when you ask it. Pulse handles the whole case under a rule you approved and leaves a record behind. The difference isn't the model — it's that authority and accountability are written down underneath it.
What if it gets something wrong?
In draft mode nothing goes out without a signature. We don't let the agent near irreversible actions, even if you ask us to.
Who is accountable?
Whoever approved the rule — same as with an internal policy. That's why it's a readable document with an author and a date, not a black box.
What happens to our data?
The first phase is read-only and audited. (To be filled in specifically: where the servers run, which model, how long data is retained, who can see it, the data processing agreement.)
Will it stand up in an audit?
For every case you can see who, when, on which verified facts, and under which version of the rule.
Does this mean layoffs?
What goes away is the work you don't actually pay qualified people for — gathering facts and retyping them between systems.
An engineering drawing describes a part. The CNC program makes it. Both say the same thing, but only one of them does anything — which is why it can't drift from what comes off the line. Business as Code (BaC) is that same paradigm for admin: the description of how a company works isn't a document about operations, it's their configuration.
A rule is a readable document. You read it and approve it like an internal policy.
A rule is also the thing that executes. It can't drift from reality, because reality is produced from it.
A rule is versioned like a contract. Every decision records which version it was made under.
Pulse is the runtime for that — a Company Operating Runtime (COR): the layer that drives the work under those rules, guards the authority limits and keeps the record. BaC is the paradigm, COR is the runtime, Pulse is its implementation.
We'll build your first process for free.** We're picking three companies and building each a working prototype — up to CZK 80,000 worth of work.
For IT: Ruby on Rails, our own Folio CMS, integrations over MCP. The agent runtime and the models under Pulse are swappable — Hermes today, OpenClaw or anything else a year from now; the know-how sits in the rules, not in the tool. You won't get BPMN, you'll get the file the thing actually runs on.
