factory-lines
Islo Factories
A Factory contains Machines, reusable Agents, and Lines. Agents are the user-facing execution units. A Line connects Agent interactions and routes their results. The runtime may compile an Agent stage into an internal Job; do not make the user choose or configure a Job. Managers route a Line between stages.
Setup contract
For a request to build or substantially change a Factory, follow factory-design.md before create-a-line.md. Inventory with read-only commands first. Distinguish observed resources, inferred defaults, and decisions still needed from the user. Ask one batch containing only unresolved decisions, then recommend one complete blueprint. Wait for explicit approval of that blueprint before any create, update, deploy, provider event, or external write.
Keep the discussion in product terms: Factory, Machines, Agents, their interactions, shared workspaces, semantic inputs and outputs, integrations, side effects, and verification. Choose a Script Agent for deterministic commands, a Decision Agent for typed choice or score questions, and a Prompt Agent for open-ended judgment or tool use. Create a user-facing or standalone Job only when the user explicitly requests the low-level Job layer.
Never write a manifest from memory. Check the installed islo schema factory --short and islo schema agent; validate before deploy. If the installed CLI lacks a required command or Agent-stage field, report the exact gap rather than silently substituting an unrelated resource. Use an internal Job only when a required capability is demonstrably unavailable to Agent stages and islo schema job --short unambiguously supports the exact requirement. If either side is unclear, report only the unresolved semantic capability and stop; do not name internal fields, propose implementation workarounds, ask the user to resolve the implementation gap, or infer support from a similarly named field. Keep an internal Job out of the user's choices and its configuration out of the blueprint unless a developer asks.