Your team decides. Aktum records who decided, and why.

The problem

AI tools flag open questions. Nobody answers them.

AI writes specs faster than your team can decide. You get more documents, fewer real reviews, and stale approvals: the file you signed last week says something else today.

The tools already show the problem. Spec Kit marks an open question [NEEDS CLARIFICATION] and moves on. The question is marked, but nobody is asked. Later, a plan answers it quietly, with no name and no reason attached. That is how your roadmap gets changed without you.

01The Record

Every decision is saved in your repository, with a name and a reason.

Sarah Bennett · decision: CL-014 answered1a2b3c4

Sarah Bennett · signoff: product on spec.md9f2c1ab

David Clarke · thread: dissent on spec.md4c8e21f

Sarah Bennett · Sarah Bennett: edit spec.mdb3d9e1f

The card above is a real file in your repository. Every decision, comment thread, approval and signature is committed as readable YAML. The commit is made in the name of the person who decided, at the moment they decided. The page shows recorded · 1a2b3c4 only after the commit lands. Before that, it says saved here, not in the record yet. Because the record is your repository's history, nobody can change it afterwards.

02The Room

Specs look like documents, not raw markdown.

2 · dissent

Notifications go out within five minutes of the triggering event.

Accepted by Sarah B. · just now

A room is where your team works on one change. The spec is shown as a document, not as raw markdown. Comments sit in the margin, next to the exact sentence they are about, and every comment is part of the record. Click a paragraph to edit it. The saved edit goes into your repository with your name on it. While you edit, the paragraph is locked and shows your name, so two people never type into the same sentence. Select a sentence and the actions appear on it: Comment, Mention someone, Explain this, Rephrase, Route a question, Strike this out.

Text written by the AI arrives as a draft: grey, italic, and clearly marked. Aktum calls this pencil. It becomes part of the spec only when a named person accepts it. Aktum calls that ink. Every acceptance shows a name and a time: Accepted by Sarah B. · just now. When a document is rebuilt, each comment re-attaches only if it still clearly matches its sentence. Unclear cases go to a tray for a person to sort out, instead of being guessed.

A signature is tied to the text it covers. If a sentence you signed changes later, your signature is marked stale. To sign again, you re-read only the sentences that changed, not the whole document. A signature you did not read is not a signature.

03The Router

Every open question goes to one named person.

CL-014 · routed to Sarah Bennett

Notification window - promptly or a number?

promptly a number

This halts the phase until it is answered.

An open question gets an id, like CL-014, and one named owner. You can also raise a question yourself, from a comment or a selected sentence. Before Aktum calls any model, it checks for open questions. If one is open, the work stops and waits: the product says This halts the phase until it is answered. The owner comes from the policy file in your repository and is chosen on the server, never by the client. Reassigning a question is not built yet. Nothing is answered by guessing.

Only the owner can answer. It depends turns the question into a discussion and keeps it open. The answer is saved as a decision with your name and your reason. If a colleague disagrees, their objection is recorded next to the decision, with their name; it blocks nothing. Questions reach you on your desk, in the room, and at the sentence itself. When nothing waits, the desk says Nothing waits on you. Nothing is blocked.

04The perimeter

Only one thing can write to your repository: the sidecar you run.

Aktum · app.aktum.io

the studio · the backend · one Postgres

work as events, results as commands,
over authenticated HTTPS

Your infrastructure

The sidecarthe one you enrol and run

outbound only, no inbound port · your model keys

branches and patches, nothing else

Your repository

repo credentials never leave your side

The sidecar runs on your own machines, and it is the only path that can write to your repository. It writes branches and patches, nothing else, and your repository credentials never leave your side. The text of your repository is uploaded to Aktum for indexing and review. Setup is a pull request, opened through the GitHub App you install and can revoke, and nothing starts until a person with write access merges it. The access tokens Aktum uses for your repository are scoped to that one repository, expire after one hour, and are never stored or logged. Model keys are yours: Anthropic, OpenAI, or any OpenAI-compatible endpoint, with Ollama as the local default. Because the write path is one component, your security team can review that one component.

05The scribe, bounded

The AI drafts. A named person decides.

draft/find · apply · delegate

Three operations. There is no fourth.

Aktum's AI signs its work as the scribe. It works inside all the rules above: the record, the room, the router and the perimeter. It writes drafts, and only a named person can turn a draft into part of the spec. Four actions are forbidden to it, and the product shows them before and after every run:

forbidden · 1Write a word of the specification.

forbidden · 2Approve, sign, or close a thread.

forbidden · 3Merge its own branch.

forbidden · 4Decide a gate rather than ask it.

The AI can do three things: draft/find, apply, delegate. There is no fourth. It never speaks as "I": machine text in the first person is rejected by the system, and CI enforces that rule. After every run, the log lists the four forbidden actions again under What it could not do. You never have to wonder whether a paragraph was machine-written: draft text looks different at a glance.

06Your method

Your way of working is a file in your repository.

.aktum/workspace.yaml

Roles, the default decider, signoff rules, how the builder is allowed to behave, whether work lands in a worktree or a branch.

.aktum/methods/

Your own method text, bound to a phase by name. Declared in the policy or found by its filename.

.aktum/skill-overrides/

One file replaces one skill Aktum ships, and the run reads yours instead. The rest keep working.

.aktum/instructions/

The standing instructions for drafting and generation, edited in the studio and committed here. Aktum's own contract stays locked above yours and is shown, not hidden.

.aktum/models.yml

Named model tiers, assigned per phase. Two or three of them on the review phase run blind and in parallel, then are revealed together.

.aktum/schema/

Nine JSON Schemas, generated from the code and committed beside your config, so your editor completes and checks your own governance file.

Aktum does not make you adopt its way of writing specs. It reads the repository and recognises the framework already in it: Spec Kit, Superpowers, OpenSpec, Kiro, or none of them. The wizard offers Spec Kit and Superpowers today; the rest are recognised where they are found.

You can change what the AI is told, in three ways, without asking us. Use a skill pack as Aktum ships it. Replace one skill by committing one file over it. Or write your own method and connect it to a phase. The order is fixed and documented: your own method wins over an override, and an override wins over what Aktum ships.

None of this lives in a settings screen. It is text committed to your repository, reviewed like any other change, and runs read it from there. aktum doctor tells you, before a run, which method files the run will use.

The loop, in five steps

01

Connect

A pull request asks the repository owner for permission. Nothing starts until a person merges it.

02

Draft in pencil

The AI writes a draft. Its text stays visibly a draft until a named person accepts it.

03

Route the question

Aktum finds each open question and sends it to its owner. Nothing continues on a guess.

04

Decide and sign

The answer goes into the record with a name and a reason, and sign-off is explicit, under a name.

05

Dispatch and review

The agent's work comes back as a diff in the room, next to the spec it implements.

Also in the product

What else is included.

Your desk

One page shows everything waiting for you, across all your workspaces: questions to answer, runs on hold, signatures to give. When it is empty, it says "Nothing waits on you. Nothing is blocked."

Review the diff beside the spec

The agent's change opens as a code review inside the room: side by side or inline, with comments on any block, next to the requirement it implements.

Two models, blind

Put two or three models on the review step. Each reviews the same change separately, without seeing the others, and the results are shown together. When they agree, that agreement means something, because neither could copy.

What it will cost, before it runs

A run shows a cost estimate before it starts, and the real cost after. Costs are summed per room, per model and per run. Prices update themselves.

Keys you can test

Model keys are yours and stay on your side. Adding one requires a second factor, and a Test button makes a real call to the provider, so you find problems now, not in the middle of a run.

The fleet

Enrol a sidecar, name it, assign it to a workspace, and watch its health. You can read exactly what Aktum asked it to do. Revoking a sidecar takes effect immediately.

A command line

aktum init, run, status, logs, doctor. Doctor tells you, before a run, which method files the run will use and where they come from.

Logs you can actually search

A live log console for your sidecars and runs. Filter by run, workspace or level. The filter is part of the URL, so you can send your exact view to a colleague.

The question finds you

A question reaches you where you already are: the bell in the product, an email where each answer is one click, or a Slack message with the answers as buttons. Answer in any of them. The decision is saved with your name, and the buttons in the other places are disabled.

Signatures that notice

If text you signed changes, your signature is marked stale, and Aktum shows you which sentences changed. A comment that loses its place goes to a tray for a person to re-attach, instead of being guessed.

Before you ask

What you need, and what you do not.

What you need

A repository. On GitHub, or on your own machines. Aktum works on the repository you already have; there is nothing to migrate.
Somewhere to run the sidecar. One component, from Docker or a checkout, on infrastructure you control. It connects outward only and opens no inbound port.
A model key of your own. Anthropic, OpenAI, or any OpenAI-compatible endpoint; Ollama is the local default. The key stays in your sidecar's environment.
Someone who can merge. Setup is a pull request titled "Set up Aktum on this repository", and it waits until a human with write access merges it.
A second factor. An authenticator app or a passkey, for every session. Your organization's policy can require it for every member, and cannot turn it off for anyone.

What you do not need

To hand over repository credentials. Repo credentials never leave your side. Repository write access exists only through the sidecar, branch and patch only.
To move your specs anywhere. The record is committed to your repository as readable text, under .aktum/, and it is readable in a text editor without the tool.
To change how your team ships. Work comes back as branches and patches you review in your own process. Aktum merges nothing.
To install anything for the team. The studio is a browser tab. Only the sidecar runs on a machine.
A card. Early access is free while the beta runs, and no plan starts by itself.

Where this goes

These are plans, not promises. No dates.

Planned: upload a recording of a meeting you already had, and get a change proposal back.
Planned: questionnaires without an account. A signed link that expires, a few short questions, and the answers become part of the record.
Planned: workshop mode. A live session where a domain expert joins by signed link, and the session ends as a change proposal.
Planned: an MCP interface, so a coding agent can send work through the same review process.
Planned: a local mode. The workspace, the checks, and the record on one repository, with no cloud and no account.
Planned: pull request checks that block a change until the spec's required reviewers have signed the current version.

Request early access

A person reads every request and replies.

Your request is stored so a person can reply to it, and your address goes on the beta list if the answer is yes. We confirm we have it, and write again if you are in. Nothing else is done with it. See Privacy and data handling.

Name

Email

Organization

Role

Where your repository lives

What you would put in the room first

Optional. One sentence is enough.

I have read and accept the terms of service and the privacy and data handling statement.

FAQ

"Another AI notetaker."

The output is a change to your repository, not a summary. Notetakers make documents about meetings. Aktum's work comes back as branches and patches against your repository, and a named person answered and signed along the way.

"Our specs are fine."

Your spec already answers questions nobody remembers deciding. A requirement says 10 requests per second, and nobody can say who chose that number. Somewhere between the meeting and the spec, whoever was typing decided it. Aktum sends that question to the person who can answer it, and records who did.

"We don't want AI writing our specs."

Neither does Aktum. The AI works under four forbidden actions, shown before and after every run. It only writes drafts, and only a named person can accept a draft into the spec.

"Where does our code go."

Only the sidecar on your own machines can write to your repository, and it writes branches and patches only. Your repository credentials never leave your side. The text of your repository is uploaded to Aktum for indexing and review, and Aktum reads your repository through a GitHub App you install and can revoke.

"What if Aktum dies."

The record survives. Everything Aktum records is committed to your repository as plain YAML files. You can read them in any text editor, in ten years, without the tool.