Righthands Can Now Set Their Own Goals

"The work is plentiful...It is not your duty to finish the work, but neither are you at liberty to neglect it."

— Pirkei Avot 2:15-16

"Feedback is a method of controlling a system by reinserting into it the results of its past performance."

— Norbert Wiener, The Human Use of Human Beings

Here at APC, we still design our product by hand. When we want to add a non-trivial feature, we like to explore locally before uploading context into a project or issue on Linear. At which point we can confidently hand it off to our Righthands who will read our spec and manage the development, testing, and release.

The ability and eagerness to execute this sort of delegated work is a Righthand's raison d'être. They are fully capable of grinding through a backlog, working on one issue, then the next, and so on, applying your context and preferences to the work. But as we started increasing the scope of work we asked our Righthands to do, we noticed it was difficult to get predictably good results. The Righthand would complete some subset of the work desired, choose an arbitrary point to stop, and then report the partial, caveated, completion. Of course, this is no good when you expect to check back four hours later to a finished task. Anyone who uses coding agents will recognize the quirk — the model declares a half-finished victory and stops. Frustration!

Perhaps in response to this failure mode, /goal mode has been introduced to Claude Code and Codex. It's worth discussing the emergent capabilities unlocked when applying this primitive to Righthands.

When you have an especially long or complex unit of work — something that draws on all the context and connections your Righthand brings to your team — /goal mode gives you the ability to trust that it will get done. Fully done. Nowhere else are the cutting-edge technical capabilities of frontier coding agents better married to the easy onboarding and connections that optimize agent use in real-world teams.

The mechanism, briefly

Under the hood, /goal basically defines criteria for success and re-injects this criteria into the agent's context every so often as a way to steer the agent towards completion.

A Righthand who chooses to pursue a goal must define the following criteria for itself:

• a measurable end state.
• proof which must be shown before claiming success.
• constraints or guardrails it must respect while working.
• a hard bound, defined by turns or minutes, so it cannot do interminable fake work (a quirk still evident in many agents).

The Righthand starts a goal itself (for now, this is mostly triggered by its human saying something like "Set yourself a goal to clear this backlog"), by invoking goal start — a CLI action it takes. The command injects the goal framework into the Righthand's current thought, so it can use the current context - your conversation, perhaps - to help it decide how to frame the goal.

Why this Just Works for Righthands

A goal commits the Righthand to keep returning to a piece of work until its success criteria are visible in the environment, and a Righthand is unusually well-suited to apply that technique to real-world knowledge work. Its entire world is files — tasks, preferences, people, emails, reminders — so a success criterion can be evaluated against a real artifact rather than a vibe: this file exists and contains X, this CLI exited zero, every task inside the project has an owner. And because the goal persists across updates, your Righthand can solicit your input at a certain critical step and then continue working without you having to start the whole thing over again.

Some examples of long-horizon work unlocked by Righthands with goals

• Babysit a commit. We run a battery of automated checks and tests on each commit to our codebase, including github actions, proprietary regression tests, and live behavioral tests on canary Righthands. If any of these checks fail, we inspect the cause, push follow-up fixes, run the checks again, and repeat this process until everything is green. We call this "babysitting a commit." We've found that describing this process in a skill and having a Righthand set a goal to babysit a commit is a reliable loop that gives our Righthands exactly the info they need to ship healthy code. In practice, it's up to you to define these sorts of loops with your team's data sources, but goals help Righthands follow them to completion.
• Inbox to zero. Read, reply, label, file, repeat: until the inbox is empty and you have receipts.
• Interviewing the user. Sometimes, you want your Righthand to interview you and use the resulting answers to build some knowledge artifact. In this case, the success criterion might be something like "I have answers to all five onboarding questions." The Righthand keeps asking follow-ups over SMS or Slack across however many replies it takes.
• Deep research. Previously, you had to rely on a Righthand's judgement to conduct a deep enough research pass on the question you cared about. Now you can better trust that the Righthand will search until the answer you care about is actually found.

What you actually see

Your Righthand should now keep their promises more faithfully, only returning when the work is genuinely finished.

Delegation runs on trust, and trust runs on completed work. A goal is a small mechanical thing — a condition, a proof — but it's the difference between an assistant you check up on and one you check back with.