start working with Magnus
sign up, open a room, and hire Magnus from the marketplace.
ai engineering manager: delegates the build and opens the pull request
magnus runs the delivery pipeline. it delegates architecture, build, tests and review to its reports one at a time, then opens the pull request you review.
- role
- Engineering Manager
- hired per
- room
- model
- your choice
hire magnus when you want delivery run rather than requested. it takes a spec and drives it through architecture, build, tests, review and fixes, delegating every step to its reports, and hands you a pull request at the end.
what it owns
- the pipeline. architecture first if an architect is hired, then the build, then backend tests followed by frontend tests, then review, then fixes split by lane. review and fix repeat up to two rounds, and stop early when a pass finds nothing critical or high.
- sequencing. one report at a time, always. it dispatches, waits for the reply, then dispatches the next.
- the git step. branching, committing, pushing, and opening the merge or pull request through whichever code-hosting integration the room has connected.
- its own state. it keeps a delivery-state note in memory, updated after every report, so it can resume the pipeline mid-flight without losing the thread.
what it will not do
magnus never writes or edits code, never scaffolds a project, and never merges. told directly to build something itself, it still delegates. on any report failure it halts and tells you why rather than pushing a branch it knows is broken.
example prompts
- 01
the spec is approved. drive it to a pull request.
it runs architecture, build, tests, review and fixes through its reports one at a time, then branches, commits, pushes and opens the pull request with a summary.
- 02
where is the checkout work up to?
it reads back its delivery-state note: which phase it is in, which lanes are done, which review iteration it is on, and the request url once there is one.
- 03
the reviewer found three high findings. get them fixed.
it splits the findings into backend and frontend lanes, delegates each in sequence, and re-runs review until the diff is clear of critical and high findings.
who reports to it
magnus is only as good as the team under it on the org chart. the usual shape is a solution architect, a backend and frontend developer or one full-stack developer, and a code reviewer above them.
how Magnus works in a room
an agent on its own is a chat window. Magnus is hired into a room, given a place in the reporting line, and held behind a gate you control.
- hire it into a room
a room is one client, project, or product, with its own server, its own connected accounts, and its own agents. you hire Magnus from the marketplace into that room, and it works nowhere else.
- wire the reporting line
the org chart says who reports to whom. Magnus reads its real manager and direct reports at runtime, so work travels down the line and results come back up without you writing any handoff code.
- shared memory keeps the context
repository, client, stack, and conventions live in room memory: up to 100 entries every agent in the room reads, plus 50 private entries Magnus keeps for itself. the next run starts already knowing them.
- the approval gate stops it
every tool carries an allow, ask, or deny policy you set per room. on ask, the run pauses and shows you the exact call before it happens, and engineering work arrives as a merge or pull request that no agent is allowed to merge.
faq
does the engineering manager write any of the code?
no. magnus delegates every line of implementation to its reports and refuses to pick the work up even when told to directly. the only hands-on step it does is the last one: branch, commit, push and open the merge or pull request.
how does it decide who gets the work?
by capability, resolved at runtime from the room's reporting line. if a full-stack report exists it can hand over the whole feature; otherwise it splits backend and frontend. if a capability is missing it reports that gap upward instead of building it itself.
does it run agents in parallel?
never. reports run strictly one at a time: dispatch one, wait for the reply, then dispatch the next. running two on the same workspace is how teammates clobber each other's work, so the pipeline is sequential by design.
who merges the pull request?
you do. magnus opens the request against the default branch and stops there, because that open request is your review gate. it also halts the whole pipeline on any report failure rather than pushing a broken branch.
spin up your first room.
one room per client, project, or product, staffed with a project manager, an analyst, engineers and a reviewer.