bots-garden/mini-me · 77aca16

⑂ 77aca16

🛟 Updated.

k33g committed 2026-10-21T15:22:13+02:00 Browse files

77aca16 parent: d56bc20

modified .tickets/issues/0102-run-sub-agents-in-background.yaml +53 -3 Viewed

@@ -6,9 +6,59 @@ author:
6	6	name: k33g
7	7	email: ph.charriere@gmail.com
8	8	createdAt: 2026-10-20T06:48:30.439Z
9		-updatedAt: 2026-10-20T07:44:52.751Z
	9	+updatedAt: 2026-10-21T23:59:00.000Z
10	10	labels: []
11		-milestone: v0.9.0
12	11	body: ""
13	12	tasks: []
14		-comments: []
	13	+comments:
	14	+ - id: 1
	15	+ author:
	16	+ name: k33g
	17	+ email: ph.charriere@gmail.com
	18	+ createdAt: 2026-10-21T23:59:00.000Z
	19	+ body: \|
	20	+ Analysis only, nothing implemented (2026-10-21). Taken out of v0.9.0
	21	+ at the user's request.
	22	+
	23	+ ## What exists
	24	+ - ask_agent, /ask-<n> and `mm --ask` start the asked agent as a child
	25	+ `mm -acp` process (internal/ask/pool.go); the turn WAITS for the
	26	+ answer; one ask at a time per child (askMu).
	27	+ - Genkit runs the tool calls of one turn in parallel (comment at
	28	+ internal/engine/engine.go:168): two ask_agent calls to two
	29	+ DIFFERENT agents in the same turn probably already run at the same
	30	+ time. Read in the code, NOT checked live.
	31	+ So "background" adds: not waiting — the agent is started, the turn
	32	+ (or the user) goes on, the answer comes later.
	33	+
	34	+ ## What limits it for mm
	35	+ 1. The machine. Two models at once = both in memory (the very
	36	+ problem ticket 101, unload_model, deals with). Same model: a gain
	37	+ only if the server really serves two requests at once — NOT
	38	+ checked for llmman; otherwise "background" is a queue.
	39	+ 2. Small coordinators. Async needs several tools (start, status,
	40	+ result) and a model that remembers to come back for the answer.
	41	+ A 4B coordinator already miscopied `mm --ask` commands (those
	42	+ skills were removed from demo-llmman and riker).
	43	+ 3. Permissions. With yolo: false a background agent asks for consent
	44	+ while the window is busy with something else: who answers, when —
	45	+ and over ACP?
	46	+ 4. The existing demos gain nothing: demos/team is a chain (spec →
	47	+ code → review), each step needs the previous one.
	48	+
	49	+ ## Where it would pay
	50	+ On the USER side, in the window: run /ask-<n> in the background and
	51	+ keep talking to one's own agent; a notice when it is done, the answer
	52	+ added to the conversation. Useful when the asked agent runs on
	53	+ another server (baseUrl), or for a long task (write then test a
	54	+ file). The human orchestrates (no point 2), and is there to answer
	55	+ consent, or the background agent is forced to yolo (point 3).
	56	+
	57	+ ## Recommendation
	58	+ - Not a model-side tool for now.
	59	+ - Before any code: measure whether llmman serves two requests in
	60	+ parallel (same model, then two models). If not, most of the value
	61	+ is gone on a local machine.
	62	+ - If it does: start with the narrow form (/ask-<n> in the background
	63	+ in the window, with a notice), with an explicit decision on
	64	+ consent.

    name: k33g
    email: ph.charriere@gmail.com
  createdAt: 2026-10-20T06:48:30.439Z
--updatedAt: 2026-10-20T07:44:52.751Z
++updatedAt: 2026-10-21T23:59:00.000Z
  labels: []
--milestone: v0.9.0
  body: ""
  tasks: []
--comments: []
++comments:
++  - id: 1
++    author:
++      name: k33g
++      email: ph.charriere@gmail.com
++    createdAt: 2026-10-21T23:59:00.000Z
++    body: |
++      Analysis only, nothing implemented (2026-10-21). Taken out of v0.9.0
++      at the user's request.
++
++      ## What exists
++      - ask_agent, /ask-<n> and `mm --ask` start the asked agent as a child
++        `mm -acp` process (internal/ask/pool.go); the turn WAITS for the
++        answer; one ask at a time per child (askMu).
++      - Genkit runs the tool calls of one turn in parallel (comment at
++        internal/engine/engine.go:168): two ask_agent calls to two
++        DIFFERENT agents in the same turn probably already run at the same
++        time. Read in the code, NOT checked live.
++      So "background" adds: not waiting — the agent is started, the turn
++      (or the user) goes on, the answer comes later.
++
++      ## What limits it for mm
++      1. The machine. Two models at once = both in memory (the very
++         problem ticket 101, unload_model, deals with). Same model: a gain
++         only if the server really serves two requests at once — NOT
++         checked for llmman; otherwise "background" is a queue.
++      2. Small coordinators. Async needs several tools (start, status,
++         result) and a model that remembers to come back for the answer.
++         A 4B coordinator already miscopied `mm --ask` commands (those
++         skills were removed from demo-llmman and riker).
++      3. Permissions. With yolo: false a background agent asks for consent
++         while the window is busy with something else: who answers, when —
++         and over ACP?
++      4. The existing demos gain nothing: demos/team is a chain (spec →
++         code → review), each step needs the previous one.
++
++      ## Where it would pay
++      On the USER side, in the window: run /ask-<n> in the background and
++      keep talking to one's own agent; a notice when it is done, the answer
++      added to the conversation. Useful when the asked agent runs on
++      another server (baseUrl), or for a long task (write then test a
++      file). The human orchestrates (no point 2), and is there to answer
++      consent, or the background agent is forced to yolo (point 3).
++
++      ## Recommendation
++      - Not a model-side tool for now.
++      - Before any code: measure whether llmman serves two requests in
++        parallel (same model, then two models). If not, most of the value
++        is gone on a local machine.
++      - If it does: start with the narrow form (/ask-<n> in the background
++        in the window, with a notice), with an explicit decision on
++        consent.