9. Delegating and autonomy modes

Delegating means letting a team role answer on your behalf whatever the workflow reserves for you (confirming, approving, accepting, choosing), following your criteria. It does not change the workflow, it does not remove the Permissions and it does not take you out of the project: you can take back control whenever you want. Everything happens in the project’s chat (chapter 8); the steps that always wait for you are set in the team editor (chapter 5).

The three modes: who decides in each

In Lyra, the reserved steps are “Ready to build” and “User test”. A team whose workflow marks no reserved step delegates everything: when you delegate, you are in Autonomous. If the delegated role is no longer in the team, the chip shows ⚠ Supervised in amber and the delegation has no effect (see Top bar, chapter 8).

How to turn delegation on

1. Press the 🤝 Delegate chip in the top bar (always visible, no menu to open). The Delegate your responsibilities dialog opens.
2. Under Who decides on your behalf, choose any role of the team (or Nobody: I decide).
3. Write your criteria (optional; for example, “Prefer the simplest option. Accept medium and low issues as pending. If in doubt, ask me”).
4. Read the box with the resulting mode, which updates when you change the role: Supervised (“Nobody decides for you…”), Semi-autonomous (“{Role} decides on your behalf, except at N steps that wait for you:”, with the list of those steps, “number. step — role”) or Autonomous (“{Role} decides on your behalf at every step of the workflow…”).
5. Choose the Actions the delegated role can do (see What the role does not do by default) and save.

It works with any team and any role: the app does not change the workflow, it only tells the agent who answers. Reserved steps are not chosen in the dialog: they are set in the team editor, under Flow (checkbox The delegated role can decide this; see chapter 5).

The strip above the chat always names the mode: “Supervised: you decide everything the workflow reserves for you.” in a neutral tone, with Delegate…; “Semi-autonomous: {Role} decides on your behalf. N steps wait for you: …” or “Autonomous: {Role} decides on your behalf at every step.”, with your criteria, Change… and Stop delegating. The chip in the top bar says the same. To stop delegating you can also press the chip and choose Nobody: I decide. When you turn delegation on, change it or turn it off (and when the workflow’s reserved steps change), the chat leaves a note and the agent learns about it with your next message (also in chats that already had a session).

Readiness warning. If, when you press Save with a role chosen, there are failing signals in Project readiness, the dialog first shows “Some signals are failing before you delegate” with the list of those signals (and how many are not checked). See Readiness closes without saving and opens the section; Turn on anyway saves the delegation; Back returns to the dialog with what you wrote. The warning doesn’t stop you from delegating.

How the delegated role decides

• Everything the workflow reserves for you (confirming the summary of a request, approving deliverables and gates, choosing between alternatives, accepting the result, deciding the next step) is decided by that role in the message itself, under a line “{Role}, on behalf of the user:” with its justification, without opening the question panel.
• At the reserved steps, instead, the role asks you with the usual panel and progress stops until you answer.
• Gate criteria. If a delegable gate has acceptance criteria, the delegated role receives them with the instruction to judge each one against the latest deliverable and cite them (✓, ✗ or not checkable, with a reason) in its decision line. If you change the criteria while delegation is on, the agent receives them with your next message. At those gates there is no separate Criteria review; at the reserved steps, there is (see The chat, chapter 8).
• If the workflow asks you to test the product, the role runs the checks it can and records each result as run on your behalf; whatever it cannot run stays not run, never passed.
• If you write in the chat, what you say prevails over the delegated role.

At what level approval happens

Approval happens per deliverable and per gate, not for every action of the agent. Within a step, the role works without asking for a new turn: it implements, checks and fixes. What gets decided (by you, or by the delegated role on your behalf) is the result of the step: the deliverable or the gate that closes it.

For example, in an implementation step the developer edits several files, runs the checks and fixes a bug, all within the same step. Nobody approves each edit: what gets decided afterwards is the test gate (in Lyra, “User test”). What can be asked action by action are the Permissions, which are a different setting (next section).

Delegation and Permissions: two separate settings

The three permission modes (the Permission: {what} dialog is explained in chapter 8, The chat):

• Always ask — asks for permission for every action.
• Accept file edits — does not ask to edit files; it does ask for commands.
• Automatic — does not ask (with Codex, it relies on its automatic reviewer).

For the sprint to move without you, set Permissions to Accept file edits or Automatic: with Always ask, progress stops at every permission even if you delegate. Delegation is a personal setting of the project (in .team-ai-console/state.json): it does not travel through git and does not affect other people on the project.

What the role does not do by default

Hard-to-undo actions still ask you even if you delegate: pushing to a git remote, deploying, deleting data, paying for or signing up to services, and widening the scope you confirmed. In the dialog, Actions the delegated role can do has six fixed actions, each with Asks me (the default) or Can do it:

• Push to the sprint branch
• Merge or push to the main branch
• Deploy
• Delete data
• Pay for or sign up to services
• Widen the scope

Allowing one of the hard-to-undo ones (main branch, deploy, delete or pay) makes the row warn “⚠ Hard to undo: the role will do it without asking you.”. They are saved with the delegation and Stop delegating clears them. The action list prevails over the steps: a delegable step such as “Push to git?” still asks you before pushing if Push to the sprint branch says Asks me.

How automatic progress stops

With delegation on, when each turn ends the app does by itself what the agent proposes, without you pressing the button: it activates the role in Switch to: {Role} (line “Automatic switch to {Role} because {Delegate} is deciding on your behalf.”), goes on with the same role’s next step instead of Continue (“Automatic continuation: {Role} goes on…”), stays in this chat when the agent proposes New chat: with the name of the chat you are already in, instead of Continue here (“Automatic continuation in this chat…”), and opens each phase’s chat even if Automatic phase chats is unchecked (“Automatic opening of the chat…”; the checkbox does not change and applies again when you stop delegating). This way the sprint moves from the interview to the end of the sprint without clicks.

It stops, and the usual button stays, when:

• the message ends in a question;
• a permission or a question is waiting for an answer (such as whether to push to git);
• the agent repeats the same proposal without the step changing;
• a reserved step arrives, which waits for your answer in the question panel;
• it proposes another sprint’s chat at the end: you open that chat.

You take back control by stopping the turn, writing in the chat or with Stop delegating: the pending progress is not made and the button stays available.

Where each decision is recorded

• In the chat: the role’s message, under “{Role}, on behalf of the user:”, with its justification.
• In the deliverable: “Decided by {Role} on behalf of the user”, with the criterion applied and the date.
• In the sprint closing: the Decisions taken on behalf of the user section, with the full list; with reserved steps, it ends with the line “Steps the user decided: …”.
• In your personal project state (.team-ai-console/state.json): the delegation, with your criteria and the allowed actions. It does not travel through git.

Review that section when you close each sprint.

What delegation does not promise

Delegation is not unsupervised execution: the team follows its workflow, you decide how much you delegate and you can take back control at any moment. The Permissions and the hard-to-undo actions stay under your control as long as you do not open them yourself. What the role decides for you is written down for you to review, and if something does not convince you, you can correct it: ask for changes or start a new round.