BlvkWare.

What the agent can reach,
and how you take it back

You are considering giving a piece of software your inbox, your calendar and your customers. That deserves specifics rather than reassurance. A BlvkWare kit is the complete specification of an agent, which you, or a developer you choose, turn into a running one. This page is exactly what that specification says about control: what the agent may do at each level, what waits for a person, what is written down, how you stop it, and where your credentials and data go. And, because it matters as much, what a kit cannot do for you.

Who is in control

You are, completely, and that is the point of a kit rather than a service. BlvkWare does not run your agent, does not host it, and never has access to your systems. The agent is built on your tools, with access you grant and can take back, and it talks to your vendors directly.

The honest consequence: the controls below are specified by us and enforced by your build. The kit writes each one down precisely, in files a developer can wire straight into code, and it says where each rule has to live. Whether it is wired in is up to the build, and the acceptance tests exist so you can check.

It starts unable to act on its own

Every tool in a kit is marked with its effect, and the agent's level decides what each effect may do.

The four levels, as the kit's policies/autonomy.json sets them out:

Every kit starts at Draft, whatever level you design towards. The policy file itself says the level must be enforced in the tool handler and not only in the prompt, because a prompt is advice and a handler is a rule. Operate is for after a supervised period at Approve, with the owner's written sign-off, and that condition is written into the policy too.

An agent is also only given the tools its job needs. A follow-up agent's kit does not contain tools for your accounting system because the same person happens to own both.

You can stop it yourself

The stop is a setting, not a support ticket. Set the level to Watch and nothing that changes anything may run. The agent can still read what comes in and report what it would have done, and it does none of it.

Two things worth being straight about. The record of what it would have done is usually the reason you stopped it: it is the fastest way to see what it was about to get wrong. And nothing already sent can be unsent, by this or by any other system. Stopping stops what has not happened yet.

What waits for a person

At Draft, every external action becomes an approval instead of an action: a record of the exact tool it would run, exactly what it would run it with, why the agent proposed it, and what it concerns. It runs only after a person approves it, edits it or rejects it, and who decided and when stay on the record. The schema for that queue is in every kit, whatever else the kit contains.

Some limits no level lifts. The rules you give while designing the agent, in your own words, are written into its instructions and its guardrails word for word, and they bind at every level. So do the kit's own: nothing is sent to a customer in quiet hours, an opt-out is permanent until the person opts back in, and the agent says it is automated whenever it is asked.

What is written down

Every kit specifies an append-only log. Each entry records when, which capability acted, what happened, what it concerned, the level in force, what decided (the model, a fixed rule or a person) and the result: done, held, refused or failed.

Two rules make that log worth having, and both are in the kit's guardrails. The entry is written before the action it records, so a process that dies halfway shows an attempt rather than showing nothing. And records are never deleted, only archived or marked. A log that can be tidied up afterwards is not a log.

Where your credentials live

Not with us, and not in the kit. A kit contains no credentials, and nothing on this site asks for one. Access is granted in your own systems, and the kit's notes for each system list exactly what the agent's tools read and change there, so you can grant the smallest access that covers it.

The kit asks for one discipline that is worth keeping even if you ignore the rest: give the agent its own login or API key, never a person's. Then everything it does is attributable to it, and it can be switched off without locking anyone out.

What leaves your systems, and where it goes

Once it is built, the agent talks to two kinds of destination, and you choose both.

• Your own vendors. The mail host, calendar, CRM or payment provider it operates, the same way you do.
• The model provider you build on, for the reasoning: the text being worked on, and whichever passages of your own material your build gives it.

None of its traffic passes through BlvkWare. We never see a message it reads or sends.

What BlvkWare does see is limited to the purchase: the answers you give while designing the agent, sent to generate the kit and not kept afterwards, and a one-way fingerprint of your licence key with the role it unlocked and how many times it has been downloaded. Gumroad handles the payment. The detail is in the privacy notice.

What can be undone, and what genuinely cannot

Some suppliers will tell you every action is reversible. It is not true and it is worth knowing where the line is.

A booking, a record update or a step in a sequence can usually be reversed in the system it happened in. Sending cannot. A message somebody has read cannot be recalled, and money that has moved may be refundable but the event still happened. This is exactly why external actions are the ones held for a person by default: the irreversible category waits, rather than being the one you hear about afterwards.

When it does not know

The failure that actually damages a business is not an agent that stops too often. It is one that answers a question about your prices or your terms with something plausible that nobody at your company ever said.

So the first guardrail in every kit is that facts come only from your records, the conversation or your knowledge base: no invented price, date, policy, phone number or promise. When that material does not cover a question, the agent's instructions are to say so and hand it to a person rather than fill the gap. A step of a written process that fails stops the process for a person; steps are never skipped. Escalation is the system working, not the system failing.

Your data, and getting it back

There is nothing to get back. The agent's records live in your own systems from the first day, in schemas you hold, so there is no export to request and nobody to request it from. The kit is yours to keep and build on for as long as you like, and your licence key downloads it again, including after you change the design.

What this page does not claim

It is a shorter list than the one above, and it is here because a page like this is only worth reading if it contains one.

• No formal certification. There is no SOC 2 report and no ISO certificate. This is a one-person company and pretending otherwise would be the first thing you found out was untrue.
• A kit enforces nothing by itself. It is a specification. The controls on this page are as strong as the build that implements them, which is why every capability comes with an acceptance test and the kit says to keep the agent at Draft until they pass.
• The agent can be wrong. Every provider telling you theirs cannot is either inexperienced or not being straight with you. What a kit offers instead is an agent specified to start unable to act on its own, to write down everything it does, and to stop when you say so. The commercial position is in the terms.