ANTECANTThe work is bigger than the conversation.
A project rarely fits inside one AI session. You explore an idea in one place, build in another, then return days later to work out what changed and which decisions still hold.
The difficult part becomes keeping the work coherent: its purpose, its limits, its current state, and the evidence behind a result.
Antecant is being built as a local-first control layer for that work. It starts with independent technical operators and founders who already use AI tools and want to direct more consequential projects without repeatedly reconstructing the context.
Three questions before more autonomy.
-
Purpose. What are we trying to achieve?
A useful brief names the outcome, the constraints, and what would count as done. It also records what is outside the task. The aim is to give each new session a clear starting point.
-
Authority. What may act, and within which limits?
Discussing an action and authorizing it are separate decisions. The product direction makes scope, approvals, and budgets explicit before execution. A request for more access should remain visible to the person directing the work.
-
Evidence. What supports the result?
A completion message is a claim. A reviewable result connects that claim to the relevant work, checks, and sources. Missing evidence should stay visible; a confident summary cannot fill the gap.
A longer memory for the work.
The model or tool you prefer today may change. Your reasons, decisions, and work history should be easier to carry forward.
That is why we are starting with durable local threads, versioned briefs, and records of the context selected for the next step. These are the foundations for returning to a project without treating the latest conversation as its entire history.
Local-first describes where the canonical work record lives. When a future workflow uses an external model or service, the context sent to that service remains a separate data transfer. Local storage alone does not make remote processing private.
The situations we are designing for.
These examples describe the intended product experience. The complete workflows are still in development.
Pick up a product change after a week away.
Return to the objective, the latest decision, the work already completed, and the question that still needs you. Continue from a useful brief instead of rebuilding the project from a pile of transcripts.
Move work between tools with its limits intact.
Take a research conclusion into implementation while keeping the supporting sources and agreed scope close at hand. The intended handoff carries the relevant context and makes any new approval a separate step.
Review an outcome before taking the next consequential action.
Inspect what changed and which checks actually ran before publishing, deploying, or spending. The goal is a short path from a claim to its evidence and to the decision that follows.
Give a new model a fair trial.
A later direction is to compare models against a bounded sample of your own work, with results, costs, and missing coverage visible. An evaluation should inform a choice; it should not silently change how future work runs.
Build the foundation. Earn the next layer.
The current development build supports local thread capture and continuation, versioned working briefs, and source-linked context receipts. Provider execution, the full approval-and-evidence workflow, and model replay are planned work.
Progress means behavior that has been built and checked on real work.
If you already direct work across AI tools, tell us where the continuity breaks. Those are the problems we want the product to earn its place by solving.