Building Medley: Autonomous agents for everyday work. Try using /mission in Claude Code.
This is the 6th launch from Spine. View more
/mission for Claude Code
Launching today
Medley is a free Claude Code plugin for work bigger than one session. Type /mission to turn an outcome into a live graph, coordinate Claude Code and Codex workers, review the result, and keep going. BYOK via OpenRouter for Kimi, GLM, and more.
Free
Launch Team / Built With
the attention queue is the part I'd want to understand before trusting this with anything real. what decides something belongs there - a fixed list of trigger conditions (destructive git ops, spend over some threshold, secrets access) or does the orchestrator itself decide mid-mission what needs a human? the first is auditable, the second has the same problem every self-judging agent has: it only escalates what it's already confident is risky, which isn't the same as catching what actually is. curious which one this is, since the benchmark numbers don't really tell me that
Spine
Great question @galdayan , Much like working with any teammate or employee you would want them to come to you for concrete things you tell them to but also if there are things they discover on their own and need your judgement on.
The product hence currently supports both:
User defined guardrails which you can see in the contract and the agents and workers actively monitor for these, and
An agent that determines when something needs user attention since for truly large and ambiguous tasks there is new information and emergent work which the user cannot always predict ahead of time.
That said, the system today does still rely on AI and is something we are always looking to improve with more code enforced guardrails and user feedback.
@ashwin_raman that's the honest answer, and it's the right one for the reason you gave - you can't write a fixed rule for emergent work you didn't anticipate. but it also means the second category is unauditable by definition, since it's the agent's own judgment about its own judgment. is there any logging on how often category 2 actually fires versus how often it should have and didn't, or is that something you'd only find out about after a mission goes wrong and someone goes looking
Spine
@galdayan One important clarification here is that we use an independent mission agent to validate and address the permissions to avoid the bias and we do maintain an activity log of the permissions that are approved by the agent and the user.
This is also why there are two levels of gating that we offer:
A gate for the workers which the mission agent can monitor
A gate for the review and replanning of emergent work
In most scenarios we found we want to run #1 autonomously (as most do today with Claude Code) and depending on the task and level of trust you might want to keep the gate on for #2 which is hence the default setting for Medley.
Spine
Ashwin here, co-founder and CTO.
We built Medley because we kept hitting the same wall with coding agents: once the work spanned multiple sessions, we became the orchestrator. We split the job up, moved context between agents, reviewed outputs, and decided what should happen next.
/mission takes on that orchestration.
Give Medley the outcome, budget, and constraints. It plans the work, coordinates Claude Code and Codex workers, reviews the result, and keeps going. Anything that needs your judgment or approval appears in the attention queue.
Before launch, we pressure-tested Medley on four public benchmarks. It set a new state of the art on all four—from coding to healthcare and drug discovery.
Missions start in Claude Code today. Medley can coordinate Claude Code and Codex workers. With your own OpenRouter key, Codex workers can also run models such as Kimi and GLM.
We’re excited to see what people hand it. Tell us what you try first, where it works, and where it breaks.
Spine
I've been using Medley to build Medley for quite a while now, and it's become one of those tools that's hard to imagine working without.
One of the coolest moments was realizing we only needed a skill in the same repo for Medley to start testing and improving itself. I'd hand it an entire feature, and it would break the work down, execute the tasks, test the implementation, and keep making progress on its own. Most of the time, it only came back when it genuinely needed my input.
What I enjoyed most was how easy it was to steer. Instead of constantly orchestrating everything, I could jump into just the part that needed my attention while Medley handled the rest. It made building Medley faster, smoother, and honestly a lot more enjoyable.
The benchmark numbers are the headline, but the line I keep re-reading is "it uses your existing subscriptions or API access."
If a mission coordinates several Claude Code and Codex workers at once, the binding constraint for most solo people isn't dollars — it's the plan's rate limit. Parallel workers on a subscription hit a wall that a per-token budget doesn't describe.
So: what is "budget" denominated in when the workers are running on a subscription rather than an API key? And does the orchestrator know the difference — does it throttle its own fan-out when it's running against a plan limit, or does it plan the graph as if capacity were unbounded and find out on the way?
orchestration is the visible problem, but the one that actually bit us was memory across sessions. splitting work between agents is fine. what breaks is session four not knowing that session two already tried an approach and abandoned it, so it walks cheerfully back into the same dead end.
so the bit I'd want is a durable record of what was attempted and rejected, not just what was decided. does the contract cover that, or only the forward-looking guardrails?
@coolstorm Since a mission runs on an outcome, budget, and constraints upfront, what happens when a long mission burns through that budget faster than planned? Does Medley scale the plan back to fit what's left, or pause and surface the tradeoff before continuing?