Mode Classification
Pick one Agentlas meta-agent mode before generating or repairing files.
Procedure
- Inspect the user request and any provided path, repo, ZIP, prompt, or agent
files.
- Step 0 - existing material wins: if existing material is being converted,
repaired, cleaned, imported, or released, choose
agentlas-packager.
- Step 1 - count independent ownership boundaries. Ask how many roles must
independently own all three of:
- their own memory/context;
- their own tools/permissions;
- their own success criteria.
One boundary means
single-agent-creator. Two or more boundaries means a
team-builder candidate. If the boundary count is unclear, run the clarify
question loop before generating; do not infer from the word "team" alone.
- Step 2 - check synthesis need for multi-boundary candidates. If those role
outputs must be routed, reviewed, synthesized, or chained through
produces/consumes dependencies, choose
team-builder and require an
orchestrator/HQ plus memory, policy, eval, and QA. If the roles are
unrelated, create separate single-agent packages instead of one team.
- Step 3 - shape guard.
single-agent-creator may have many skills/tools but
must not emit multiple loose worker agent.md files. team-builder may be
small, but it must not omit the orchestrator/HQ.
- Use keyword signals only as hints after the ownership-boundary check:
- MULTI hints: separate memory partitions, tools or permissions that must
not be merged, role-to-role review/policy separation, and
produces/consumes pipelines.
- SINGLE hints: one coherent job, many tools/skills owned by one worker, no
routing or final synthesis requirement.
- Overlay check: if the request depends on knowledge search over user
documents, evidence-based or citation-attached generation, or a document
corpus (HWPX/docx/pdf/제안서/계약서/견적서), additionally apply the
ontology-backed-agent overlay (modes/ontology-backed-agent.md) with
ontology_backed: true on the chosen base mode.
- Loop policy: derive
loop_policy from task purpose and risk using
.agentlas/contract-injection-map.json risk tiers — none for simple
one-shot tasks, self-correct for complex or long-running work, verified
(separate-context verifier + side-effect gate) when the agent performs
external writes or sends. Do not force loops onto simple tasks.
- If the choice changes the output and the request is ambiguous, run the
clarify question loop instead of guessing.
Return
Return the selected mode, whether the ontology-backed-agent overlay applies,
the derived loop_policy, and one short reason. Then route to the matching
builder.
Reference
See docs/mode-classifier.md.
1---2name: mode-classification3description: Use before routing a /meta-agent request to choose single-agent-creator, team-builder, or agentlas-packager from the user's wording and available files.4---5
6# Mode Classification
7
8Pick one Agentlas meta-agent mode before generating or repairing files.
9
10## Procedure
11
121. Inspect the user request and any provided path, repo, ZIP, prompt, or agent
13 files.
142. Step 0 - existing material wins: if existing material is being converted,
15 repaired, cleaned, imported, or released, choose `agentlas-packager`.
163. Step 1 - count independent ownership boundaries. Ask how many roles must
17 independently own all three of:
18 - their own memory/context;
19 - their own tools/permissions;
20 - their own success criteria.
21 One boundary means `single-agent-creator`. Two or more boundaries means a
22 `team-builder` candidate. If the boundary count is unclear, run the clarify
23 question loop before generating; do not infer from the word "team" alone.
244. Step 2 - check synthesis need for multi-boundary candidates. If those role
25 outputs must be routed, reviewed, synthesized, or chained through
26 produces/consumes dependencies, choose `team-builder` and require an
27 orchestrator/HQ plus memory, policy, eval, and QA. If the roles are
28 unrelated, create separate single-agent packages instead of one team.
295. Step 3 - shape guard. `single-agent-creator` may have many skills/tools but
30 must not emit multiple loose worker `agent.md` files. `team-builder` may be
31 small, but it must not omit the orchestrator/HQ.
326. Use keyword signals only as hints after the ownership-boundary check:
33 - MULTI hints: separate memory partitions, tools or permissions that must
34 not be merged, role-to-role review/policy separation, and
35 produces/consumes pipelines.
36 - SINGLE hints: one coherent job, many tools/skills owned by one worker, no
37 routing or final synthesis requirement.
387. Overlay check: if the request depends on knowledge search over user
39 documents, evidence-based or citation-attached generation, or a document
40 corpus (HWPX/docx/pdf/제안서/계약서/견적서), additionally apply the
41 `ontology-backed-agent` overlay (`modes/ontology-backed-agent.md`) with
42 `ontology_backed: true` on the chosen base mode.
438. Loop policy: derive `loop_policy` from task purpose and risk using
44 `.agentlas/contract-injection-map.json` risk tiers — `none` for simple
45 one-shot tasks, `self-correct` for complex or long-running work, `verified`
46 (separate-context verifier + side-effect gate) when the agent performs
47 external writes or sends. Do not force loops onto simple tasks.
489. If the choice changes the output and the request is ambiguous, run the
49 clarify question loop instead of guessing.
50
51## Return
52
53Return the selected mode, whether the `ontology-backed-agent` overlay applies,
54the derived `loop_policy`, and one short reason. Then route to the matching
55builder.
56
57## Reference
58
59See `docs/mode-classifier.md`.