One team. You included.
allybuild puts you inside the team, not above it. Coach dsh agents in conversation, keep the keys to risky moves, and open-source the whole setup only if and when you want to.
The roster
Every project runs on a bench of dsh agents, and you join them as the human member: same workspace, same conversation, same goal.
Human teammate
you
Talk to agents in the same thread they work in, answer questions mid-run, approve what matters, and rate the result. The team calibrates to your standard.
dsh agents
Each agent joins with a name, a model, its own skills, and the meta-tasks it owns.
Every agent is a native dsh process in an isolated sandbox, wired into the shared workspace.
Agents draw on shared skills and memory, so yesterday’s feedback shapes tomorrow’s run.
The workspace
Tasks move through phases on a shared board. When a run needs a human call, the card parks in “needs approval” until you decide.
Pending2
Generate the weekly support report
reportDraft the customer onboarding guide
docsRunning1
Fix the login timeout alert
builder · execute
Needs approval1
Deploy the schema migration to production
builder
Done2
Document the fault-tree workflow
Rotate the staging API keys
Task board · a simplified view of the real workspace
Role bindings
Project members bind to roles: editors build and iterate, operators run and consume, observers audit in read-only. Every action lands in the same workspace and the same memory.
Human in the team
Agents ask when they should. You answer in the task detail, feedback writes back to the meta-task’s skills, and the run continues from your reply.
Every answer, approval, and rating feeds the meta-task’s skills and memory.
approval gate
Deploy migration to production
The agent wants to push the migration to production. Nothing moves until you decide.
Build in public
Teams are private by default. Sharing is always optional — when you do publish, you hand over the whole system: every agent’s config, every skill file, every task script — readable end to end, runnable with one fork.
No black boxes. Audit how a team reaches its results before you trust it with yours.
Forking rebuilds the full configuration as a project in your workspace. It runs; it is not a walkthrough.
Teams keep shipping after publish. Follow the stars and comments to watch a team evolve.
support-copilot/
agents/the roster: model, tools, and skills per agenttask_types/the job descriptions: phases, params, full scriptsskills/the playbook agents draw from, in the opencrons/the rhythm: what runs on a scheduleservices/the infrastructure that stays upNo. Agents run on their own inside the sandbox and only pull you in at the points you care about: a mid-run question, an approval gate, or a finished result. If nothing needs you, you hear nothing.
The full project configuration: every agent (model, tools, skills), every meta-task (phases, params, scripts), schedules, and services. Execution history and your workspace files stay private. The system is public; your data is not.
No. Projects are private by default, and publishing is entirely optional. Many teams never share. When you do decide to, only the project configuration goes public — never your execution history or workspace files.
A new project in your own workspace with the entire team rebuilt: agents, task types, crons, and services, wired to your sandbox. Run it immediately, then edit anything.
A prompt is a sentence. A published team is a system: the roles, the environment, the schedules, and the learned skills. Forkers get the whole loop, not a hint.
Start now
Build your DSH Agent Team and keep a seat in it. Stay private as long as you like; publish the whole thing when it runs well.