Install to first task
Last updated: 20 September 2026
Aiglade doesn't produce the intelligence itself — it's a dispatch console. The work is done by command-line agents already installed on your machine. So the first step is confirming those exist.
Step 1: check the agents run on their own
On launch, Aiglade detects which agents are available locally and lists them. It finds them by itself; you don't point it at paths.
One practical tip: run one agent in a terminal first and confirm it answers, before using it through Aiglade. Otherwise, if something fails inside Aiglade, you can't tell whether the problem is Aiglade or the agent's own setup.
Step 2: dispatch something simple
Don't test with a real project the first time. Pick an unimportant directory and give it a small, clear task.
| Good first task | Why |
|---|---|
| "Read the README in this directory and summarise it in three sentences" | Read-only; nothing breaks if it's wrong |
| "Rename every .txt in this folder by its modification date" | Clear goal, obvious whether the result is right |
| "List the dependencies this project uses and their versions" | Pure information gathering, no judgment involved |
Avoid "refactor this module" as a first task — the bigger the goal, the harder it is to judge whether it went well.
Step 3: watch one run end to end
Stay with it the first time. Watch how it breaks the task down and picks actions, and you'll get a feel for its temperament: does it read before editing, or start changing things immediately? When stuck, does it stop and ask, or try another direction on its own?
That observation is worth more than any documentation. Agents differ noticeably — the same task might draw caution from one and recklessness from another.
Three places people get stuck
Installed, but not detected
Usually it's installed somewhere Aiglade doesn't look, or under a different user. Check whether the command runs in your terminal under the current user — if it does, it's on PATH.
Task dispatched, nothing happening
First check whether it's waiting for approval. Consequential actions are held, and a pending item appears in the interface. That's the design working, not a hang.
Two agents, two different results for one task
Expected. Different agents use different models and organise context differently, so the same brief gets read differently. That's an argument for running several: you get two proposals to compare.
Next
- Splitting work across agents — which tasks parallelise cleanly
- What the approval gate is for — what gets held, and how to stop it nagging
- Attaching a key you already have — the four common failures whose errors don't name the cause
- Checking that it actually finished — three silent false successes; "no error" proves nothing
- When a task stalls or fails — running, waiting, or already dead