mirror of
https://github.com/langchain-ai/deepagents.git
synced 2026-07-24 20:35:31 -04:00
Mason Daugherty
8fca61dc03
Adds rubric-driven acceptance criteria to Deep Agents Code and layers a goal workflow on top of it. A rubric is the explicit definition of done. Use it when you already know the criteria the agent should satisfy before it considers the work complete. Criteria can be sticky for the thread, one-shot for the next turn, or loaded from a file. While the agent works, the TUI shows grading lifecycle messages so the user can see when the work is being checked, revised, satisfied, or stopped. Usage examples: ```text /rubric set tests pass; no unrelated files changed; help text is updated /rubric next only change the auth callback; do not refactor unrelated code /rubric file acceptance.md /rubric show /rubric clear ``` A goal is the objective-oriented workflow. Use it when you know the outcome, but want `dcode` to propose acceptance criteria before execution. `/goal <objective>` asks the model to draft criteria and displays them in an inline review prompt. The user can accept the criteria, edit them directly, reject them with feedback to regenerate, or cancel. Accepted goal criteria become the sticky rubric for the thread. Usage examples: ```text /goal add OAuth refresh handling /goal show /goal clear ``` The `--goal` CLI flag starts the same goal-review workflow when launching the TUI. It is intentionally interactive: the generated criteria must be reviewed before execution. After the user accepts the proposal, the accepted goal is sent as the first task. ```bash dcode --goal "add OAuth refresh handling" ``` `--goal` cannot be combined with `-n`, `-m`, `--skill`, or `--rubric`. For non-interactive/headless runs, users should provide criteria explicitly with `--rubric` instead: ```bash dcode -n "implement OAuth refresh handling" --rubric "tests pass; no unrelated files changed" dcode -n "implement OAuth refresh handling" --rubric @acceptance.md ``` Accepted goal/rubric state is persisted on the thread and restored on resume. For example, a user can set `/goal add OAuth refresh handling`, accept the proposed criteria, quit the TUI, and later resume the same thread with the goal and criteria still active. That matters because the acceptance criteria continue to guide future turns and remain visible in `/goal show` instead of becoming hidden context that disappears between sessions. When the agent believes the goal is done, it does not get to declare victory on its own. For example, after implementing OAuth refresh handling, the agent can ask to mark the goal complete with evidence such as "tests pass." `dcode` keeps that request pending until the rubric check finishes. If the rubric still needs revision, the goal stays active and the user sees why it was not completed. If the rubric is satisfied, auto-approve mode records the completion automatically; manual mode asks the user before changing the goal status. This keeps the user's accepted criteria as the source of truth for whether the goal is actually finished. The active criteria and goal are also visible to the agent through constrained tools. `get_rubric` lets the agent inspect the current criteria and whether they came from a goal, a sticky rubric, or the current invocation. `get_goal` lets it inspect the active objective, status, criteria, and any prior note. `update_goal` lets it report when it believes the goal is `complete` or `blocked` with evidence. The constraints matter: the agent can read criteria and update progress, but it cannot create, pause, resume, clear, or replace goals. Those lifecycle actions stay user/system controlled so the model cannot silently redefine or remove the user's objective.