feat(agent): multi-action requests (adopt stoa FinalIntent) - #47
Merged
Conversation
…caps Adopt stoa v1.0.9's FinalIntent so one bookkeeper request can perform several actions (e.g. reverse a wrong entry then re-post the correction): - bookkeeping.Intent gains a top-level `final` flag and IsFinal(); the model marks its last action final and the loop executes it then stops. A lone post is itself final, so the common single-action request stays one turn. The intent schema requires `final`; the prompt teaches when to set it. - Every entry point is multi-action (Intent implements IsFinal): TUI, book-run, and bench. MaxTurns defaults raised 3 -> 8 to fit a correction (recall + reverse + lookup + final post); maxPostsPerRequest caps postings against a runaway loop independently of the turn budget. Multi-action requests are not yet atomic (each action publishes as it runs); bookkeeping.Staging will make the batch all-or-nothing in the follow-up. Tests: multi-action reverse-then-repost in one Book; prompt teaches the final action; existing fakes mark their single action final. Docs in the same change. Closes #43.
flarexium
added a commit
that referenced
this pull request
Jun 12, 2026
…caps (#47) Adopt stoa v1.0.9's FinalIntent so one bookkeeper request can perform several actions (e.g. reverse a wrong entry then re-post the correction): - bookkeeping.Intent gains a top-level `final` flag and IsFinal(); the model marks its last action final and the loop executes it then stops. A lone post is itself final, so the common single-action request stays one turn. The intent schema requires `final`; the prompt teaches when to set it. - Every entry point is multi-action (Intent implements IsFinal): TUI, book-run, and bench. MaxTurns defaults raised 3 -> 8 to fit a correction (recall + reverse + lookup + final post); maxPostsPerRequest caps postings against a runaway loop independently of the turn budget. Multi-action requests are not yet atomic (each action publishes as it runs); bookkeeping.Staging will make the batch all-or-nothing in the follow-up. Tests: multi-action reverse-then-repost in one Book; prompt teaches the final action; existing fakes mark their single action final. Docs in the same change. Closes #43.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #43. Part of the multi-action epic (#45).
What
One bookkeeper request can now perform several actions — the canonical case is "reverse that entry and re-post it at the right amount" (a
reverse_journalthen apost_journal) in a single request.FinalIntentloop).bookkeeping.Intentgains a top-levelfinalflag +IsFinal(). The model marks its last actionfinal: true; the loop executes it and stops. A lone post is itself final, so the common single-action request is still one turn. The intent schema requiresfinal; a "Completing a request" prompt block teaches when to set it.IntentimplementsIsFinal— TUI,book-run,bench.MaxTurnsdefaults raised3 → 8(fits a correction: recall + reverse + lookup + final post);maxPostsPerRequest(=12) caps postings against a runaway loop independently of the turn budget.Not yet atomic
Each action publishes as it executes, so a request that fails after its first action leaves that action committed.
bookkeeping.Staging(already merged, #42) is the mechanism to make the batch all-or-nothing; wiring it into the agent is the follow-up (#44). Called out in AGENTS.md and docs/architecture.md.Tests
TestAgent_MultiActionReverseThenRepostInOneRequest— oneBookdoes reverse (not final) then post (final); 2 turns, 3 entries (original + reversal + correction).TestPromptRenderer_TeachesFinalAction— the completion rule is in the prompt.final(otherwise multi-action loops to MaxTurns).go build/vet/test ./...green; gofmt clean.🤖 Generated with Claude Code