simmisfirst agent branch
An illustrative founder scenario that follows a partner decision from assignment through review.
Illustrative scenario. No completed founder run underlies this example. The scenario explains the intended product model, and available data connections depend on the deployment.
the assignment
A technical founder wants an agent to evaluate a potential distribution partner, propose updates to the partner record, and draft an implementation plan with internal tasks. The recommendation should compare strategic fit, implementation cost, major risks, and unanswered questions using approved company context and permitted research sources. Outbound communication remains a separate assignment requiring its own authorization.
1. choose the Team and pin the basis
In this scenario, the founder would start in the relevant Team, where earlier product decisions and partner criteria already live. Simmis would record the exact basis so the founder could judge the result against the context available at delegation time.
2. define the outcome and the bounds
The task would ask for a recommendation of about two pages with an evidence table, proposed partner record changes, and an internal implementation plan. The founder would permit read access to selected internal material and approved research tools, deny outbound communication, set a spending limit, and require the run to stop at that limit.
Why this boundary matters. The assignment would grant the authority required for the work and withhold everything else.
3. fork a contained workspace
Simmis would create a branch from the basis. Notes, extracted facts, draft files, proposed record updates, internal tasks, and relevant execution context could change inside it. The branch would keep those changes separate from the Team's accepted managed state while the agent worked.
4. perform the work and keep receipts
The agent would read the allowed context, gather permitted evidence, and draft the brief, record changes, implementation plan, and internal tasks. Tool use, sources, checkpoints, and spending would form part of the run record. The result would name any unavailable connection as a limitation and leave the resulting gap unresolved.
5. return a proposal
The branch would become a proposal that packages the brief and proposed state changes with a semantic diff, provenance, cost, and rationale. The proposal would be ready for judgment but would remain outside accepted managed state.
6. review with founder judgment
The founder would check the recommendation and proposed operational changes, follow important evidence to its source, inspect cost and tool use, and decide whether the remaining uncertainty was acceptable. The founder could request a fresh attempt with narrower or different bounds.
7. decide and retain the history
If accepted, the proposal and its record, plan, and task changes would enter accepted managed state. If discarded, the parent would stay untouched. In both cases, the attempt and decision history would record who delegated the work, what ran, what it cost, and what decision followed.
If accepted managed state moved during the attempt, conflict handling would compare the proposal with its pinned basis and reveal competing changes. The reviewer would still make the business judgment.