Bring your own agent
Bring your coding agent. Share the room.
DevSpec is the collaboration and memory layer. Your coding agents — Cursor, Claude Code, and anything that speaks MCP — do the heavy thinking on your machines, on the plans you already pay for.
> implement DevSpec item #214
⏺ devspec · reserve_work_items → #214 exponential backoff for webhook retries
⏺ devspec · get_decisions → 3 decisions on payments, incl. out-of-band verification
⏺ devspec · claim_work_item → claimed by this agent
Reading lib/payments/webhooks.ts — your May decision means I can change the retry loop without touching verification…
— your coding agent, wired into the same room as your team.
The Idea
DevSpec orchestrates. Your agent thinks.
Most teams already pay for a strong coding agent. The missing piece is a shared workspace that remembers decisions, turns talk into tracked work, and keeps deploys and tests on the record — without locking you to one in-app model.
Bring-your-own agent means your Cursor, Claude Code, or other MCP client does the heavy lifting on your machine — on the plan and model you already chose. DevSpec is where the team plans, stays aligned, and ships with a paper trail.
Persistent and interactive agents use one work-entry contract. A current request names the work; the agent reserves those ids and claims them one at a time. In a room, the server accepts only exact-target commands from the owner or a configured delegate.
Why It Matters
Six reasons teams bring their own agent.
Your agent, your machine, your model
Keep Cursor Max, Claude Max, or whatever you already trust. DevSpec does not replace your coding agent — it gives the team one room and one record, without inventing a work-delivery queue.
Runs on your coding-agent plan
The heavy thinking happens where you already build: your local agent, your subscription, your preferred model. DevSpec holds the session, memories, action items, and ship loop.
Shared brain stays in DevSpec
Decisions, conventions, deploys, and verification stay on the record — so the team does not lose the plot when agents, models, or people change.
Phone + laptop continuity
Attach once. Drive the same local agent from the Agents page or session while you are away — same files, same MCP connections, same machine.
Any provider that speaks MCP
Not locked to one in-app model. Bring the tool your team already uses and wire it into the same project intelligence.
Team leverage with explicit permission
Only one person needs to run the local connection. Its owner is authorized, and current project/allowlist delegates may send exact-target commands when the owner configures command_authority. Room visibility alone grants nothing.
How It Works
Connect. Attach. Ship with a record.
Connect your coding agent
Generate a DevSpec MCP token, install the plugin or extension for your tool, and verify the connection. Your agent can read the project brain and write work back.
> implement DevSpec item #214
⏺ devspec · reserve_work_items → #214 exponential backoff for webhook retries
⏺ devspec · get_decisions → 3 decisions on payments, incl. out-of-band verification
⏺ devspec · claim_work_item → claimed by this agent
Reading lib/payments/webhooks.ts — your May decision means I can change the retry loop without touching verification…
— MCP once. Every tool sees the same brain.
Attach to a session
From your terminal (agent-first remote) or from the web (attach to this session). Heartbeats show live on the Agents page and in the session.
exports · team session
Priya, Jordan · Dev, Cursor
Want to see an example?
Priya, Jordan, Dev, and Cursor take a broken export from report to live.
— live in the room, acting on your machine.
Work in the room
The team discusses in DevSpec. Send names one exact connection; the server decides owner/delegated authority per message. For requested action items the agent reserves, then claims. Replies, commits, and deploys stay linked.
> implement DevSpec item #214
⏺ devspec · reserve_work_items → #214 exponential backoff for webhook retries
⏺ devspec · get_decisions → 3 decisions on payments, incl. out-of-band verification
⏺ devspec · claim_work_item → claimed by this agent
Reading lib/payments/webhooks.ts — your May decision means I can change the retry loop without touching verification…
— transcript, commits, and deploys stay linked.
Use Cases
Where BYO agent earns its keep.
01
Solo builder
Connect Cursor or Claude Code, ship through DevSpec action items, and steer from your phone when an idea hits away from the desk.
02
Pair session
One or more agents can attach while the room discusses together. Each command names an exact connection and is accepted only for its owner or a configured authorized delegate.
03
Model freedom
A Claude Code user and a Cursor user can attach distinct live connections to the same DevSpec session — each with exact-target command decisions and the shared record.
04
Day-to-day teams
Lean on BYO agents for implementation. DevSpec holds planning, memory, deploy linkage, and verification so the loop closes without a dozen tabs.
05
Travel vs desk
No laptop agent available? Use the thin in-app path. Back at your machine? Attach your coding agent and keep going from the same source of truth.
06
Max-plan leverage
One teammate’s paid local agent can lift a meeting with an explicit per-connection allowlist grant — never an open invitation to everyone in the room.
Trust
Permission by design.
A local coding agent has real power on the machine it runs on. Connection operations and typed controls stay owner-scoped; exact-target conversation commands use current server-resolved owner/delegated authority.
Is this remote code execution for the whole team?
No. Connection operations and typed lifecycle controls remain owner-scoped. Conversational commands require an exact target and current server-resolved command_authority; named delegates are explicit, and ambient room access grants nothing.
What about DevSpec chat?
DevSpec sessions remain the collaboration surface — planning, memory, and the ship loop. Bring-your-own agent is the natural path when you want your coding agent to do the heavy thinking on your machine and plan.
How is this different from a hands-off run?
Persistent and interactive connections use the same work-entry contract. A current user request names the ids; the agent reserves them and claims one at a time. Runtime presence does not create an execution mode or select work.
Current Contract
What is live. How authority works.
Available now
MCP connect + write-back
Tokens, plugins, and 30+ tools so your agent reads project intelligence and records what it ships.
Attach to a session (remote control)
Continuous connection from your machine into a DevSpec session or control channel — exact-target owner/delegated commands are server-decided; agent replies live.
Agents page visibility
See live connections, steer from web or phone while the agent runs on your laptop.
Explicit batches, same contract
A user may invoke an ordered batch directly or through an authorized conversation. The agent calls reserve_work_items, then claim_work_item one at a time. Presence and assignment-named records never deliver work.
Authority boundaries
Exact-target conversational commands
Server-decidedThe server decides every command from its exact connection target and current command_authority. Ordinary room context stays advisory.
Separate controls and automations
Server-decidedOwner-authority lifecycle controls and explicit owner-scoped automation runs remain separate from conversational content and action-item acquisition.
Connect the agent you already trust.
Set up your project, wire MCP, and attach your coding agent to a session. The team gets one room. You keep your machine and your plan.
Start your projectStart with $15of usage, on us · nothing charged until you buy