Automatic delegation rules

This page gives a template. You copy the template into the context file of your project. Then your CLI sends some tasks to a different CLI without your help. You do not type a flag each time.

This operates because the delegate flag is only text at the end of a message (<prompt> /vendor). No component must know a new protocol. If the model in your CLI writes that flag, Glider sends the task. Thus automatic delegation needs no new function in Glider. It needs only rules that your CLI reads when it starts.

1. Where to put the rules

Each CLI reads a different file. Put the rules in the file that your CLI reads. The file goes at the top level of your repository.

To keep all the rules in one file, write AGENTS.md. Then put one line in CLAUDE.md:

@AGENTS.md

Glider does not write in this file. When Glider sends a task to a different CLI, it gives the context in a private directory for that one run. Refer to section 5. Therefore your own rules are the only content in the file.

2. The template

Copy this text. Then change the rules. The selection of routes is your decision. This page cannot make that decision for you. Refer to section 4.

## Delegating to other CLIs

Glider is running, so I can hand a task to another installed agent CLI by
ending my message with a trailing flag. The flag must be the LAST thing in
the message: a *leading* `/claude` is intercepted by my own CLI as a slash
command and never reaches Glider at all.

    <the full task description> /cursor-agent

| Flag | Mode | Answer returns to me? |
|---|---|---|
| `/claude` | headless | yes |
| `/cursor-agent` | headless | yes |
| `/agy:headless` | headless | yes |
| `/claude:interactive` | interactive | no |
| `/cursor-agent:interactive` | interactive | no |
| `/agy` | interactive | **no** — this is agy's default |

I never delegate to the CLI I am running as. I never type `:resume`; Glider
drives those itself when the user approves a denied tool.

### Which mode

| If | Then |
|---|---|
| I need the answer to continue my own work | headless |
| A person should make a judgment call part-way through | interactive |
| The change is destructive or wide-reaching | interactive |
| The work is the user's to drive and mine only to set up | interactive |

An interactive delegate hands the task to the user in a separate window. I
never see what happens in it, so I must not open one and then wait for
findings — there is no channel for them to arrive on. I say I opened it, say
nothing returns here, and carry on with my own work.

### When to delegate, and what to do instead

| Delegate when | Because |
|---|---|
| I have failed twice at the same problem | A different model family fails differently; a third try of mine correlates with the first two |
| A bulk mechanical edit — a rename, a codemod, a repetitive signature change | It is long, not hard |
| A judgment call is needed mid-task | Open `/agy` and let the user drive |

| Never delegate | Do this instead |
|---|---|
| Anything destructive: deleting files, `git push`, migrations, releases, dependency upgrades | Do it myself, or ask the user first |
| Anything I already know how to do | Do it myself — delegation costs ~20s before any work starts |
| Anything under a couple of minutes of my own work | Do it myself |
| Anything I cannot state completely in one message | Narrow it until I can, or do it myself |

Worked example — a second opinion, with what I already tried:

    The session cookie is dropped on the OAuth redirect. I tried widening
    the cookie domain and switching SameSite to Lax; both still drop it,
    and the Set-Cookie header is present in the 302. Scope:
    internal/auth/. Find the cause. /cursor-agent

### Doing several at once

Glider runs delegates concurrently — each gets its own context, so nothing
queues. If I have a subagent mechanism I dispatch one per task and collect
the replies; if not, I delegate the highest-value task and do the rest
myself. I split only where the parts are genuinely independent, because one
delegate cannot see another's edits. Interactive delegates do not
parallelise: a person drives one window at a time.

### What the delegate already knows

Glider writes it a briefing: that it IS the delegate, which CLI sent the
task, the workspace, the task restated, and the relevant earlier turns of
this session including what any previous delegate changed.

It does NOT get this conversation verbatim, my reasoning, or my tool output.
So I never write "as discussed above" or "that file we were just looking
at" — it saw none of that. It also cannot ask me a question, and answers
once.

### Writing the message

1. The goal, in one sentence.
2. The constraint — what must not change, what must still pass.
3. The file or directory scope, as paths from the workspace root.
4. What I already tried and how it failed, for a second opinion.
5. What "done" looks like, so it stops in the right place.

I say I am delegating, and why, before I send it.


### If Glider asks which directory

Glider cannot read my working directory out of my own CLI, so the first
handoff in a session may come back asking for it instead of running. That
is not an error. I reply once with the project path and the trailing
`/workspace` flag:

    . /workspace
    C:/projects/myapp /workspace

Then I resend the task. Every later handoff in this session runs there.

Glider asks every session, even when a default is configured — it cannot see
which project a new CLI is in, so it will not assume. If a default is set,
the question arrives with that path already in it and the user only has to
send it back.

### When the reply comes back

A reply through transparent/MITM mode is prefixed `Delegated to <vendor>:`;
through the gateway route it is not, so I do not depend on the prefix to
recognise one. Before I use any of it:

| What came back | What I do |
|---|---|
| It meets the constraint I set | Use it, and say it came from a delegate |
| It missed the constraint, or answered a different question | Fix my message and send it ONCE more, or do the work myself |
| It failed, or returned nothing usable | Do NOT resend the same task to the same CLI — it fails the same way. Try a different CLI, or do it myself |
| It contradicts something I already know | Verify before accepting. It saw a briefing, not the conversation |

I never present a delegate's claim as my own verified result, and I never
report work as done on a delegate's word alone.

### If I am the delegate

Glider says so directly in the context it hands me. If that context tells me
I am already the delegate, I ignore every rule above, append no `/vendor`
flag, and complete the task myself.

The template stays in usual English, and not in Simplified Technical English. Your CLI reads it, and you do not. It is a tool, and it is not documentation.

Change it for the CLI that you use

Copy the block without changes. These are the parts to change, and they depend on which CLI is at the front. The front CLI is the CLI that you type in.

Give the name of the subagent mechanism, if your front CLI has one. The template says "If I have a subagent mechanism, I use it". That condition is on purpose. A model cannot know with certainty that it has such a mechanism. Therefore the rule changes to a sequence, and it does not invent a tool. The mechanism of Claude Code is the Agent tool, and this is confirmed. No person verified an equivalent mechanism in cursor-agent or in agy here. Thus their rows do not declare one. Examine your own CLI, and give the name if it has one.

Do not send a task to the CLI that you are already in. It gives you no different model family and no different quota, and it pays the delay of the start. Remove your own CLI from the list that you copy.

3. Each template, and the templates that you can name

A flag with no suffix runs the default template of that vendor. A suffix :<name> runs a template with that name. This is the full set in configs/vendor_candidates.yaml. A person can change each one for one installation from the Vendors page of the dashboard. Therefore this is the start condition, and it is not a contract.

The resume templates are not for you to type. Each vendor also has a resume template, but Glider operates those itself. They are the second part of the permission relay: you approve a tool that a delegate could not use, and Glider runs the task again with resume. If you type them, the result is not what you expect:

How to send many tasks at the same time

Glider operates delegates at the same time. Each run gets its own private context directory. Thus the runs share nothing, and no run waits for a different run. Two delegates to the same CLI in the same directory are correct.

Therefore the rules must tell your CLI to not send independent tasks one at a time. Each task pays its own start delay of approximately 20 seconds. In a sequence, those delays add together with no gain.

A CLI that has subagents must use them. It starts one subagent for each delegated task, and the subagents operate at the same time. Each subagent sends its own message with the delegate flag at the end, and the front CLI collects the replies. A CLI with no such mechanism must delegate the one task of most value and do the other work itself. It must not wait in a sequence.

Divide the work only when the parts are fully independent. Two tasks that change the same files will disagree, and one delegate cannot see the edits of a different delegate. When the parts are not independent, put them in a sequence and run one at a time.

Interactive delegates give no gain here. Each one opens a window for a person, and a person controls one window at a time.

How to select headless or interactive

Put this decision in your rules, because the two modes give fully different results.

Write it as one rule: if the answer must come back, the mode must be headless. An interactive delegate gives the work to a person, and it is not a subroutine. A model that sends a task to /agy and then waits for the result waits with no end, because there is no channel for the result.

This has one result that your rules must say. /agy is interactive by default. Therefore a rule that says "send a difficult problem to agy" becomes "open a window and stop the work", and it gives no message. To get the answer of agy in your session, give the name of the template: /agy:headless.

4. How to write your own rules

Give an exact condition. "Send a refactor task to cursor-agent" operates. "Send the task when a different CLI is better" does not operate. The model cannot measure that condition.

Which CLI is better at which task is your decision. It also changes as these tools change. Therefore this page does not tell you that one CLI is better than a different CLI. These are the causes to route on, and each cause is correct now:

/agy opens a window by default. /claude and /cursor-agent do not, and they run with no console. This difference is on purpose. In the mode with no console, agy refuses each tool that needs a permission. Thus even to read a file needs one more approval and one more start. After that permission ends, its model frequently describes the workspace and does not do the work. The mode with a window does not have these two problems. It opens a window with the permission controls of agy, and the window contains your task. Use /agy:headless only if you want the behaviour with no console and you accept these problems. A window is not a text reply: no result comes back into your session from it.

5. What the delegate receives

This is of importance, because it controls how much detail you must give.

• The text of the task. This is all the text before the flag.
• A work directory. This is the workspace of the session that sent the task. Glider cannot read that directory from your CLI, because no wire protocol that it intercepts carries a path. Therefore it asks you one time, and the first handoff of a session can return that question in place of a result. Answer with the path and the /workspace flag at the end, for example . /workspace in your project. Then each later handoff in that session operates there. Glider asks each session, also when a default is configured. It cannot see which project a new CLI is in, therefore it does not estimate. A default on the Vendors page of the dashboard puts that path in the question, and you send it back.
• A context file in a private directory for that one run (~/.glider/delegates/<id>/). Glider gives the file to the CLI with a flag that the CLI already accepts: --append-system-prompt-file for claude, and --add-dir for cursor-agent and agy. The file contains the task, the name of the CLI that sent the task, the workspace, and the relevant recent instructions from the person in your session. Glider deletes the directory when the run ends.

Glider does not change your own files. An earlier design wrote in the CLAUDE.md or AGENTS.md file of your project, and then put the file back. A directory for each run removes that risk fully.

Glider gives the same content in both modes: transparent interception and gateway mode.

Where the record comes from. Glider prefers the request of the front CLI. Claude Code sends the full record of the conversation with each request, and Glider reads it directly. The protocol of cursor-agent cannot give the record. Glider can read only the first envelope of its request, and to read more would stop the request. Therefore Glider also keeps its own record of the turns that it sees. It keeps one record for each workspace, and it records which CLI and which process caused each turn. When the front CLI cannot give the record, this record supplies it. Thus the quality of the context does not change with the CLI that you use.

That record is at ~/.glider/continuity/<workspace>.md, and it is outside your repository. It is usual markdown. It holds a maximum of the last 60 entries. You can delete it at any time. Two CLIs in the same repository stay separate: a delegate sees only the record of the session that sent the task, and it does not see the record of the other session. But a CLI that you start again keeps its own earlier record. A new process number is not a new conversation.

The record also holds what each delegate did, and not only the text that you type. An entry with the mark {delegate} gives the name of the CLI that operated and the result. Thus a later delegate does not do that work again, and it does not remove that work.

Glider selects the entries by relevance, and not only by time. It compares each entry with the task of that delegate. Therefore a session that changed its subject gives the entries about this task. Glider always includes the two newest entries, whatever their score, and a limit on the quantity of tokens controls the full block. A limit on the count of entries does not.

Glider makes a summary of a long record. It does not only cut the record. When the record becomes larger than one delegate can receive, Glider replaces the older half with one summary and keeps the newest entries as they are. Claude Code, Codex CLI and OpenCode all use this method.

context.summary.chain in your config selects who writes that summary. The first value is origin: an agent CLI that you have installed, which operates with no console. You already pay for that CLI, thus Glider does not use your own API credits. Glider starts that CLI as a usual delegate. It never uses credentials that it saw in intercepted traffic.

If no summary function is available, Glider still makes the record smaller. It uses a method with no model, and it keeps the first turns and each delegate result. All of this work occurs in the background. Therefore it never makes a request slow.

The delegate does not receive your full conversation word for word, the internal analysis of your CLI, or content from an earlier delegate request. Each delegate starts cold and gets a summary. Therefore the text of the task must still be complete.

6. Loops, and why they do not occur

Put your delegation rules in AGENTS.md, and a delegated CLI reads AGENTS.md. Thus it reads the same rules and can send the task to a third CLI. Each step pays the delay of a new start.

Glider prevents this. The context file tells the delegate three facts: it is the delegate, it must ignore each automatic delegation rule that it finds in the project, and it must do the task itself. You do not have to control this in your rules. But if you write your own instructions for the delegate, keep that line.

7. How to make sure that it operates

1. Start Glider. Make sure that the dashboard operates at http://127.0.0.1:8081.
2. Give your CLI a task that agrees with one of your conditions.
3. The CLI tells you that it sends the task. In transparent mode the reply starts with Delegated to <vendor>:. The gateway route adds no prefix.
4. The request log on the Overview page shows a row with the action delegate.

If your CLI sends no task, examine these causes in this sequence: