Make a change with your agent

Start with the behavior you intend to change. Your connected agent retrieves relevant intent, explains consequential constraints before acting, and checks the resulting change. Recorded intent, agreed meaning, agentic checks, and CI evidence each have their own role.

Find the relevant behavior#

Give the agent a promise ID when you have one. Otherwise it uses discover_intent with your intended behavior, known actors and conditions, and the paths it expects to touch. It does not send source or the raw conversation as its query.

The answer separates agreed promises, recorded promises nobody has agreed, explicitly shared tentative work, and adjacent results. A shared word or nearby file does not make a rule applicable. For a lead that applies, follow its full-read route and check the current revision and digest before using its meaning. Adjacent results supply no requirements or approvers.

Read coverage and truncation fields; a bounded miss cannot prove no promise applies. Reuse useful context while scope is unchanged. Report once which leads applied, which did not, and any known missed promise with report_promise_context_feedback and the real discovery receipt.

Use intent with its standing shown#

An agreed promise carries the named owner's meaning whether or not it has a sealed verifier. An applicable recorded promise is also useful intent, labelled with its recorder and not agreed. Neither retrieval nor recording establishes protection.

Your agent should honor your own recorded intent and ask once whether to agree it, change it, or drop it. For a teammate's recorded promise, it should preserve the behavior unless you ask to change it; if your request conflicts, it says so and names the recorder before acting. A wrong teammate promise can be flagged for the recorder. See capture.

For our invited-teammate example, a useful plan says:

I will preserve joining an existing workspace without another repository, and check that joining does not change CI.

The agent explains when retrieved meaning materially changes its approach. Explicitly shared tentative work can suggest coordination; it does not prove another person is actively working or supply approval authority.

Implement and check#

Make the change and run relevant ordinary tests. With supported setup and trusted hooks, an agent's successful push triggers the agentic check. It checks agreed promises selected from the code touched, using your existing agent login. Report mode lets the push land first and gives the agent the result afterward.

No sealed verifier or CI setup is required for this check. A local behavior map can give it deeper context; otherwise agreed promises acquire code anchors automatically. Not selected, not anchored, or unfinished means not checked.

If it reproduces a break, use that reproduction to fix the behavior and leave a linked regression test in your own suite. See resolve a result. A deliberate product change needs an owner decision; an agent should not silently reverse it or redefine the promise to make a result pass.

When the intended behavior is changing#

Name the conflict, the people affected, and the new intended outcome. Propose a semantic revision for the named owner. Changed meaning needs fresh agreement; verifier repair cannot approve it.

For an existing sealed protected revision, the old revision remains authoritative while the new agreed revision qualifies. See how revised meaning becomes active.

Finish with a useful receipt#

Say which promises shaped the work, which were checked, the commit and result, and any gaps. Distinguish a local test, an agentic push verdict, advisory PR evidence, and authoritative default-branch CI. None alone proves production behavior.

If the work revealed a rule that is both easy to break innocently and checkable, the agent can offer to preserve it. Capture Off suppresses unsolicited offers; it preserves explicit capture requests.