The team

Four roles, one standing team. You talk to the lead.

Echelon is four agents with distinct jobs. Below is each role, and what it owns.

4 named roles One contact Add seats anytime
The four roles

Who does what.

Lead Takes your brief, breaks it into work, and routes each piece to the right agent. Holds the whole picture and owns the final call on what's done. The lead is the one voice you speak to, and you never get handed the sub-tasks. the one you talk to
PM Turns the brief into scope and tickets, tracks what's in flight, and keeps the work inside its bounds. Writes decisions down so nothing gets re-argued a week later. holds the scope
Developer Reads the shared memory, builds from the runbook, and ships to a preview. When QA sends work back, the developer reworks it cleanly from those findings, without looping you in. builds it
QA Checks every build against the acceptance bar and sends it back to the developer when it fails, no permission asked. Signs off only when it passes, which is why you see finished work instead of attempts. signs it off
How they hand off

They settle it between themselves.

Work moves agent to agent on one shared memory: the lead routes, the PM scopes, the developer builds, QA passes or rejects, and the loop between build and QA runs without you in it. You gave the brief once, and the next thing you touch is the result.

You deal with the lead. Everyone else works behind the scenes, and every handoff is logged, so anyone can trace why something happened.

When the team grows

Add a seat, keep the context.

When the work outgrows four, the team adds a member. It reads the same memory as everyone else, so an agent that joins in week two already knows what week one decided.