# Four ways to compose agent work AgentRun connects open-ended agent work, focused Jev system one decisions, and code. These four examples show different compositions of the same primitives. The website draws each graph from its actual DSL and replays events recorded by the interpreter. The examples use fictional evidence, prewritten model responses, and teaching policies. They demonstrate execution and decision boundaries, not live research or model accuracy. The business examples do not implement an institution's compliance policy. ## Run a sample From the source directory with Node 22.19+: ```sh npm ci npm run build node examples/workflow-gallery.mjs research node examples/workflow-gallery.mjs kyb node examples/workflow-gallery.mjs adverse node examples/workflow-gallery.mjs mcc ``` Each example also has an `uncertain` scenario: ```sh node examples/workflow-gallery.mjs kyb uncertain node --test examples/workflow-gallery.test.mjs ``` Read the [executable examples](../examples/workflow-gallery.mjs) and [boundary tests](../examples/workflow-gallery.test.mjs). The research question is an input; the sample uses generic research angles so the workflow can be discussed without committing to one research topic. ## Exploratory deep research A typed LLM step proposes subquestions. A `map` applies the same research agent instructions to each question, with a limit on concurrent work. The results become a list of findings. Jev sifts the findings for usefulness, and a pick can select a follow-up worth investigating. A final agent consolidates the retained evidence and unresolved questions. **What becomes simpler:** one research recipe runs across a list of questions. Change the recipe once; every mapped investigation uses the new version. The planner, relevance judgment, and report writer have distinct inputs and outputs. `decide` is available for focused typed LLM work; `agent` is available for work that may need a host's tool loop. Both use the host's `runNode` interface. Jev's `sift`, `pick`, `judge`, and `route` use `runJudge`. ## Know the business behind the name An agent discovers a company's entities and people. A mapped judgment classifies each record, then a router sends it to a researcher with the appropriate instructions. A company record and an officer record need different questions answered. The workflow checks completeness against the teaching rubric declared in its judgments. A bounded loop follows up on missing information. A final judgment records the review outcome and an agent writes the report, preserving unresolved items. **What becomes simpler:** the shape of the research follows the discovered ownership structure. You do not manually write a branch for each subsidiary or officer. Classification, specialist research, completeness, and risk review are separate boundaries. The policy is illustrative. Its classifications and outcomes are not a legal determination, and the report does not authorize onboarding or rejection. ## Find the right person in the noise Several search agents investigate different sources. Their results are candidate records, not confirmed facts about the subject. Identity judgments distinguish a supported match, a different person, and insufficient identifying evidence. The workflow retains those distinctions through follow-up and reporting. **What becomes simpler:** search breadth and identity resolution are separate. A strong name match does not silently become an adverse finding. `sift` can retain several confirmed records; `pick` is appropriate when choosing one next lead. They are not interchangeable. A bounded search can finish without establishing a match. That means no supported match was found in the examined evidence, not that adverse information cannot exist. The final output supports a human review; it does not make an employment decision. ## Classify a merchant using an SOP Start with approved instructions and a supplied catalogue. Route to the merchant's website when available, or to discovery when it is missing. Establish which business the sources describe, investigate aliases, and identify what the merchant actually sells or provides. Compare candidate catalogue entries, apply the full relevant policy, and check the selected entry against the exact supplied row. **What becomes simpler:** evidence collection, assignment policy, catalogue values, and report writing have separate owners. Updating the catalogue need not rewrite the research agent. A changed policy can be tested before activating it. The public example uses a newly authored teaching policy and demonstration catalogue. It contains no private processor SOP or real merchant records. Its row identifiers are not payment-network MCC assignments. Website, directory, registry, and alias discovery are patterns the host can implement; the offline sample does not contact those services. ## Read the graph | Construct | What it owns | | -------------------- | ------------------------------------------------------------------------ | | `decide` / `extract` | A focused LLM task with a declared output schema. | | `agent` | Open-ended work inside one defined task; the host supplies its tools. | | `map` | Apply a body to each item; collect outputs with bounded concurrency. | | `parallel` | Run independent, explicitly authored branches together. | | `judge` | Produce a typed judgment from a declared rubric. | | `sift` | Apply the same judgment to a list and retain matching items. | | `pick` | Select one supplied option, optionally allowing no choice. | | `route` | Choose and execute a branch. | | `loop` | Repeat a body until a condition holds or the iteration bound is reached. | | `code` | Apply exact execution rules and validate exact identifiers. | A child `workflow` can contain maps, loops, routes, parallel branches, and other children. Its state and schemas remain isolated; the parent owns terminal report and artifact delivery. See [typed authoring](authoring.md) for a reusable research component and [host integration](host-integration.md) for recovery requirements and older-host limits. A loop reaching its bound is not proof of success: a later step must inspect the remaining gaps and decide what to return. Similarly, a judge returning a schema-valid value is not proof that its conclusion is correct. ## Evaluate a boundary Keep the complete rubric with the judgment you test. For example, an identity test needs the same matching, contradiction, and uncertainty criteria as the full workflow. Testing only a name comparison would evaluate a different system. The example tests check routing, repeated work, retained uncertainty, and result contracts. `runIdentityEvaluation()` also runs the same complete identity classifier against three saved cases, plus a deliberately wrong name-only match. That wrong answer completes execution but fails the expected outcome. To evaluate model quality, replace the scripted adapters with your configured host and use representative inputs with independently chosen expected answers. Then rerun the whole workflow to check the interaction between steps. ## Connect a live host The browser uses recorded fixture results. The exported workflow definitions can be passed to `runWorkflow(workflow, input, { runNode, runJudge })` with matching inputs. Your host owns the model configuration, tools, cancellation, accounts, and external effects. Follow the [host contracts and Jev setup](guide.md#jev). The planned Pi extension would help author, validate, evaluate, and run these same definitions in a Pi session. The existing [Pi SDK](../packages/pi/README.md) is available from source; the native extension remains a proposal.