For AI agents: the complete documentation index is available at https://jig.md/llms.txt, the full documentation bundle is available at https://jig.md/llms-full.txt, and this page is available as Markdown at https://jig.md/guide/workflow-design.md.
Jig
DocumentationGuidePrerelease

#Choosing a workflow structure

View Markdown

Use the smallest structure that makes the important correctness, information, authority, and lifecycle boundaries visible. More Agents and more steps do not create assurance by themselves.

This guide helps choose a design; it is not a list of current Jig features. The direct-alpha guide defines what Jig supports today.

Code and Agent work share a Flow boundary. Choose their arrangement inside a method before adding orchestration around it. The request-triage example shows one caller using code, an Agent, or both without changing its calling model.

#Put each concern where it belongs

ConcernPut it here
Parsing, arithmetic, validation, allow-lists, candidate construction, and stopping rulesOrdinary deterministic code
Interpretation, extraction, drafting, or judgment that exact code cannot expressOne bounded Agent call
Task-specific guidance or reference materialAn explicitly selected skill; a skill supplies context, not authority
Ordering, branching, joining, or bounded repetitionPackage code; use a graph when inspecting, testing, or reusing the topology is valuable
Tests, retrieval, compilers, fuzzers, simulations, benchmarks, or human reviewEvidence supplied to a check, gate, or loop
Best-of-N, tree search, evolutionary search, prompt optimization, or another specialized algorithmA reusable Flow or library, not a Jig primitive
Admission, exact identity, isolation, credentials, deadlines, and resource limitsThe Jig host
Publication, payment, device control, legal approval, or another consequential actionThe owning application, person, or narrowly authorized capability

One method can occupy several rows. A test-driven repair loop, for example, combines deterministic tests, an Agent judgment or edit, and bounded repetition. The table places each concern where it can actually be implemented or enforced; it does not force the whole method into one category.

You do not need a dedicated Jig feature for every workflow method. Implement the method in the Flow, and rely on Jig only for the boundaries the host must enforce. A prompt can request a limit or permission, but only ordinary code or the host can enforce it.

#Add structure only for a stated reason

  1. If exact code can produce and check the result, use one reviewed Run.
  2. If one part needs interpretation or generation, give only that part to one Agent. Keep validation, stopping, and effects in code.
  3. If the work has distinct steps, start with a fixed sequence, branch, fan-out/join, or bounded loop. Add a graph when its topology needs to be inspected, tested, or reused.
  4. Add Agents only when roles need materially different evidence, skills, information access, or authority—not merely different personas.
  5. When a model chooses what happens next, construct the complete eligible set outside the model. Accept one allowed identifier or abstention, validate it, and invoke only the pre-authorized target.
  6. Put durable activation, shared resources, credentials, and consequential effects behind a real owner. Do not imitate them with conversational memory or an indefinitely running Flow.

These are design choices, not maturity levels. A useful application may need no Agent, no graph, or no host-managed service.

These established approaches can provide a useful starting point when a simple sequence is not enough:

The orchestration-pattern catalogue explores reusable structures that may be especially useful in Jig applications.