Class CustomerReportDoer

java.lang.Object
ai.redouble.nucleo.harness.AbstractJob<CustomerReport>
ai.redouble.nucleo.tools.AbstractTool<CustomerQuestion, CustomerReport>
ai.redouble.nucleo.tools.AbstractOrchestrator<CustomerQuestion, CustomerReport>
ai.redouble.nucleo.tools.AbstractDoer<CustomerQuestion, CustomerReport>
ai.redouble.examples.doer.CustomerReportDoer
All Implemented Interfaces:
GuardedExecution, ScopeAuthority, Identifiable, Job<CustomerReport>, Doer<CustomerQuestion, CustomerReport>, Orchestrator<CustomerQuestion, CustomerReport>, Tool<CustomerQuestion, CustomerReport>
public class CustomerReportDoer extends AbstractDoer<CustomerQuestion, CustomerReport>
Orchestration written in Java. Where an agent leaves the order of the work to the model, a doer states it in code: look up every order of one customer in parallel, then ask a model one question over what came back. Use a doer where the steps are known, and an agent where the model should decide them.

A doer is a tool: the same @ToolName and typed input and output, so an agent could call it and code submits it like any job. Each lookup is a new tool created with this doer as its parent, so it appears under the doer in the record of the run. nextStep() plus submitInCurrentStep fan the lookups out into one step, all running at once on virtual threads of their own; submitInStep gives the model call a step after them. The step numbers are how the record shows what ran side by side.

A doer holds nothing while it waits: its execute has no resources parameter, and each job it runs asks for what it needs and holds it only while it runs. A hundred doers waiting on their lookups hold no connections between them. LLMReadableCheckedException.unwrap passes the runtime's retry signals through and reports anything else as a failure the caller can read.

Since:
0.1 (2026-09-27)
Author:
Andrey Santrosyan