Documentation Index
Fetch the complete documentation index at: https://developer.kodexa.ai/llms.txt
Use this file to discover all available pages before exploring further.
AGENT steps delegate a bounded part of an Activity to an agent runtime. Use them when the workflow needs tool use or multi-step reasoning, but the Activity Plan should still own the business process boundary.
Agents should help the platform build, inspect, draft, or decide within a well-defined scope. They should not replace the Activity Plan as the workflow model.
When to Use AGENT
Use anAGENT step when the Activity needs an agent to:
- Draft a routine Data Form, schema, or Activity Plan segment for review
- Investigate a document exception using project context and tools
- Assemble test cases for a configured extraction or review workflow
- Compare document evidence against configured business rules
- Produce a structured recommendation that a reviewer or downstream step can use
LLM for a single bounded prompt. Use AGENT when the work involves tools, iterative reasoning, or multiple project resources.
Basic Shape
| Config key | Description |
|---|---|
agentRuntimeId | Agent runtime that should run the work |
moduleRefs | Optional modules/tools made available to the agent |
dependsOn | Prior Activity steps or actions that must complete first |
How It Runs
When the step becomes ready, Kodexa:- Resolves the agent runtime.
- Confirms the runtime is available.
- Applies runtime concurrency limits.
- Creates an agent run linked to the Activity step.
- Supplies project, task, document family, module, and step metadata.
- Marks the Activity step running until the agent completes or fails.
Keep the Boundary Tight
Good agent steps have a tight contract:- Clear input context
- Clear expected output
- A finite tool set
- A known completion condition
- A downstream consumer for the result
Example: Exception Investigation
Concurrency
Agent runtimes can have concurrency limits. If a runtime is at its limit, the Activity step remains pending until capacity is available. This protects shared runtimes and keeps agent-heavy workflows from overwhelming project resources. Design with this in mind:- Put expensive agent steps after cheap deterministic routing.
- Use
SCRIPTorLLMfirst when they can filter out clean cases. - Keep agent steps reserved for cases where tool-using reasoning is worth the latency and cost.
AGENT vs LLM vs SCRIPT
| Need | Use |
|---|---|
| Deterministic routing or simple transformation | SCRIPT |
| One prompt with mapped output | LLM |
| Tool use, investigation, or multi-step reasoning | AGENT |
| Human ownership of a decision | CREATE_TASK |
Outputs
Agent outputs should be structured enough for downstream steps to consume. A useful agent result normally includes:- A concise recommendation
- Evidence references
- Confidence or risk level
- Missing information
- Suggested next action
Checklist
- The agent runtime is available to the project.
- The Activity Plan gives the agent a narrow job.
- The agent has only the tools/modules it needs.
- The workflow still has deterministic downstream steps.
- Human review owns final judgment where required.
- Concurrency and latency are acceptable for the business process.
LLM Steps
Use bounded prompt execution instead of agent delegation.
Create Task Steps
Hand agent recommendations to human reviewers.
