What Ark is not

The fastest way to trust a tool is to know exactly where it stops. Six things Ark deliberately is not.

Not a Cursor replacement

Ark uses Cursor underneath: builders, reviewers, and verifiers are Cursor agents dispatched via the SDK. You keep using Cursor interactively around Ark. Ark adds the orchestration layer Cursor does not have: decomposition, parallel isolated worktrees, independent review, cost attribution, and outcome verification.

Not a ticket queue

Jira remains the system of record for tickets. Ark consumes tickets as evidence inside intents and posts results back to them. If you are pasting a single ticket into Ark, stop and read Intents, not tickets.

Not autonomous merge

Builders never merge. Merge requests are reviewed and merged by people, on every repo. The two person gates, align before any run and accept before proven, cannot be delegated to an agent. Architecture sign-off on auth, secrets, payments, and tenant isolation is a person decision.

Not a black box

Every stage leaves an artefact you can read. The intent spec carries an append-only run log of every cycle. Every agent run writes a ledger row with tokens and cost. Evidence folders hold the probes, red/green transcripts, screenshots, and SIT reports. ark status shows a live view of a running intent, and the board shows everything else. If you want to know what Ark did, the answer is in git, not in anyone’s memory.

Not free, and not pretending to be

Every intent carries a budget. Spend is reconciled hourly against real Cursor billing, planning windows have burn tripwires that stop new dispatches, and the board shows charged dollars next to every intent. An intent that costs more than its outcome is worth is a failed intent, and the ledger will say so.

Not magic

Ark refuses work it cannot do properly. The environment doctor blocks a full-lane run on a machine without the capabilities the lane needs, such as scratch-org provisioning or Jira credentials. Lane policy demands probe evidence before decomposition. A green test suite does not close a defect; the fix must be verified on an org through the path the customer reported.

"It feels like a black box"

That feeling is real on a first run, and the answer is not faith. It is the artefact trail. Open the intent file and read the run log from top to bottom: what the probe found, what the red test asserted, what the reviewer objected to, what it all cost. Then open the evidence folder and look at the screenshots. The system is designed so that skepticism has somewhere to go.

If a run log cannot answer your question, that is a defect in the intent, and worth raising.