Work in stages, each one checked.

You can ask your team for anything in a message, and for small requests you should. Work that matters is cequenced: passed through a series of stages, each producing a required deliverable before the next can start. You can then see what was asked, what was specified, what was built and what was checked, as separate, attributed steps.

One-shot prompting

One model, one pass, one opinion.

Ask a model directly and it interprets the request, decides the approach, does the work and judges its own output in one pass. When the result is wrong, there is no record of which step went wrong.

  • The requirement and the solution are written by the same author
  • Nothing checks the work except the model that produced it
  • You get an answer, not evidence

Cequenced

Separate stages, each with a gate.

The request is framed, specified, built, planned for testing and tested by different roles, and none can move on until its deliverable exists. It is the separation of duties a careful team uses, enforced by the platform.

  • Whoever writes the spec does not build it; whoever tests it did not write it
  • A stage cannot close without its deliverable
  • The result comes with its evidence

Each role hands a deliverable to the next.

Work flows left to right and cannot skip. Each hand-off is gated on the deliverable of the stage before it.

1CoordinatorFrames the askFramed request
2Requirement authorsSpecifies what, not howSpecification
3ImplementorsBuilds to the specWork item
4QA plannersWrites the test plan independentlyTest plan
5QA executorsRuns the plan, records resultsTest results
1

The Coordinator frames the ask.

Coordinator

You provide the brief. The Coordinator turns it into a request the team can act on: what is being asked, for whom, what is out of scope, and which roles it will pass through. The original wording is kept verbatim as the root intent, which the rest of the cequence traces back to.

The Coordinator delegates; it does not build. Its tools are scoped to creating and assigning tasks, so it cannot quietly do the work itself.

Deliverable

A framed request with a recorded root intent

The task tree is created, roles are assigned, and the founding request is attached unchanged to each descendant task.

Gate: no requirements work can be assigned until the framed request exists.
2

Requirement authors say what, not how.

Requirement authors

The specification describes the outcome: what must be true when the work is done, what inputs exist, what constraints apply, and how success will be recognised. It deliberately does not prescribe the approach. Keeping the how out of the spec leaves the Implementors free to choose the method while still being held to the outcome.

The spec is the contract the QA planners will later test against, so it has to be concrete enough to be checked.

Deliverable

A specification document

Attached to the task as a saved file, with acceptance criteria the subsequent roles can read.

Gate: implementation cannot start until the specification is attached. A stage marked done without it is refused.
3

Implementors produce the work item.

Implementors

Code, a document, a campaign, a data set, a configuration change: whatever the work is, the Implementors produce it as the spec describes. They have the tools to build and the credentials the role was granted, and nothing more. They cannot write their own acceptance criteria and they do not sign off their own work.

Where the output is code, the work is committed and the commit is part of the record. Where it is a document, the document is attached to the task. Either way, the artifact has to exist as a file the platform can see.

Deliverable

The work item, as an artifact

A committed change or an attached file, hashed and bound to the task. Claims in the hand-off note are checked against what was actually produced.

Gate: QA cannot begin on a task whose declared deliverable is missing.
4

QA planners write the tests without looking at the answer.

QA planners

The test plan is written from the specification, not from the implementation. The planners ask: if the spec is satisfied, what must be observable? They list the checks, the inputs, and the expected results. Because the plan comes from the specification and not from the implementation, it catches the cases where the work satisfied the builder but not the requirement.

Deliverable

A test plan

A committed plan artifact naming each check and its expected result, ready for someone else to run.

Gate: execution cannot start until the plan exists.
5

QA executors run the plan and record what happened.

QA executors

The executors work through the plan as written and record the result of each check: pass, fail, or could not run. For software, that can include driving the application in a real browser against a preview deployment. Executors have no authority to change the plan or the work; a failed check goes back to the stage that caused it, as a task, with the evidence attached.

Deliverable

Test results

A results record against the plan, with the artifacts the checks produced. When the checks pass, the cequence is complete and the output can be certified.

Gate: a project can require a live implementation certificate before a change may be merged.

Cequenced work comes with evidence.

Because the stages are separated and gated, the platform can record who did what, from what, and prove it later. Three layers, from the activity feed to a document an auditor can verify without an account.

Audit

Task logs, attributed.

Each stage's tool calls, messages, state changes and attachments are timestamped and attributed to the role that took them. Claims made in a hand-off are checked against the record before you see them. The log exports to CSV.

Provenance

From root intent to artifact.

The verbatim founding request, the delegation through each role, the sources each agent consulted, and the model that ran each step, captured as the work happens, and viewable for any project.

Certificates

Signed, and verifiable offline.

For any artifact, generate a Provenance Certificate: a signed document binding the intent, delegation, sources, model runs and verification steps to the artifact by hash. The public key is published; a bundled verifier checks the signatures and hashes independently.

What a certificate contains

Each line answers a question an auditor would ask. Shown for a marketing email; the certificate is the same for any artifact.

Artifactlaunch-email-v3.md · sha256 9f2c…e41aWhich file, and a fingerprint that changes if a single character does.
Root intent"Write the launch email for the September release." Sarah, 09:02Who asked for it, in their own words. Proves the work traces to a human decision.
DelegationCoordinator → Requirement authors → Implementors → QA planners → QA executorsThe steps it passed through. Shows the spec and the tests came from different roles.
Sourcesrelease-notes.md · pricing.html · 3 prior tasksWhat the agents read to produce it, so a claim in the email can be traced to its origin.
Model runs5 · providers and prompt versions recordedWhich models did the work and how they were instructed. Matters when a provider changes.
VerificationTest plan: 7 checks · 7 passedThe independent checks it survived before anyone approved it.
SignatureEd25519 · cert-signing-v1 · validProves none of the above was edited after issue. Anyone can check it against the published key.

The same cequence on a sales campaign.

Substitute the deliverables and the stages are unchanged. Here the brief is "build an outbound campaign for mid-market logistics companies."

1CoordinatorFrames the campaign: segment, goal, what is out of boundsCampaign brief
2Requirement authorsDefine the ideal customer profile, qualifying criteria and what a booked meeting must include, not how to find themICP & qualification spec
3ImplementorsResearch accounts, build the target list, draft the outreach sequence to the specTarget list & sequence
4QA plannersFrom the spec alone, write the checklist: "each account has 200–2,000 employees and operates a fleet", "each named statistic links to a source", "no account on the do-not-contact list", "each email has one call to action"Review checklist
5QA executorsTake each check and run it against the actual list and copy: open the account records, follow the source links, compare against the exclusion list, and record pass or fail per itemReview results

The campaign that goes out carries a certificate: who asked for it, the profile it was built against, the sources behind each claim, and the checks it passed. The same holds for a financial close, a policy document, or a quarterly report.

Not every task needs a cequence.

Ask an agent a question, get a draft, have a topic explained: freeform is fine, and it is still logged. Cequence the work you would not accept from a colleague without a spec and a review: a release, a customer-facing document, a financial record, a change to production. The cost is the hand-offs. The return is a result checked by a different role from the one that produced it.

  • Freeform for questions, drafts and exploration
  • Cequenced for anything that ships, is sent, or is relied on
  • Human review can be required at any hand-off
  • Roles run in Cequenced Cloud or on a satellite, and the cequence is the same

Run your first cequence.

The Basic plan needs an API key and nothing else.

Create your account →Where it runs