Inflara / Product & systems architecture
Complex agents.
Reusable workflows.
A system for turning human intent into coordinated, inspectable agent work.
Abstract
Inflara is an agentic workflow system for building purpose-built agents and reusable automations. It gives multi-step work an explicit structure: who acts, what context they receive, which evidence they produce, how failures are handled, and when a person must decide.
The same foundation can coordinate a layered researcher, repeat a support-triage process, or supervise software delivery. These are different applications of one execution model. The workflow is a durable definition; each run supplies new inputs, maintains its own state, and produces a traceable outcome.
Inflara combines a visual workflow graph, a supervisor, native agent workers on paired machines, structured handoffs, and project operations. Its value lies in the process around an agent: reusable coordination, bounded execution, evidence checks, and recoverable work.
Chapter 01
From answers to repeatable work
A capable model can investigate a question or complete a focused assignment. Operational work usually has a larger shape: gather evidence, separate responsibilities, compare approaches, validate outputs, manage exceptions, and repeat the process with fresh inputs.
When that structure lives only in a conversation, every run asks an agent to reconstruct it. Context expands, handoffs become ambiguous, and successful completion is difficult to distinguish from a persuasive summary. Adding more agents can increase these coordination costs.
Inflara makes the process editable and reusable. Users can build a graph directly or ask Inflara Assistant and a supervisor to draft one. They can inspect the roles, branches, inputs, model choices, and gates before execution. A saved graph can become an operational recipe or the internal reasoning structure of a purpose-built agent.
Define how the work gets done. Preserve the process. Supply the next question.
A deep researcher can combine parallel discovery, sector specialists, evidence consolidation, contradiction review, and an independent final audit. The workflow defines how layered that investigation becomes and what qualifies as a supported conclusion.
Chapter 02
The execution model
Inflara separates the work definition, its coordination, and its execution. Machine choice and provider choice become part of a controlled system rather than an implicit property of a chat session.
Goals, input material, constraints, and human decisions.
Assignments, dependencies, branches, limits, and evidence.
Authorized work on a laptop, server, or provisioned VM.
The coordination layer
The application stores workflow definitions, run and node state, assignments, decisions, artifact records, and supervision history. A supervisor can scope a request, select or draft a workflow, assign roles, monitor progress, and respond to interactions within its authorized scope.
The execution layer
Runner pairs a machine with an Inflara instance, advertises detected agents and capacity, claims authorized jobs, and reports progress and completion. Supported worker adapters include Codex, Claude Code, and Antigravity. Their native tools can support analysis, research, document work, or code changes, subject to the adapter and the machine owner’s policy.
Workspace selection
Coding runs use mapped folders and, where applicable, isolated Git worktrees or a shared workflow branch. Artifact-only runs use authorized input, output, and scratch directories without a repository checkout or Git finalization. Artifact-only execution requires an adapter that can enforce the filesystem boundary and a strict output contract; selecting the mode alone does not establish support.
Chapter 03
A language for complex agents
A workflow is an executable graph with typed nodes and directed edges. Independent eligible branches can run in parallel; downstream joins and decisions make their dependencies explicit. This supports small recipes and larger systems with nested responsibilities.
| Primitive | Responsibility |
|---|---|
| Task, prompt, and agent-role steps | Perform bounded work with selected inputs, instructions, worker, model, effort, and output expectations. |
| Decision branches | Route on upstream status, verification, confidence, or structured values using configured rules or judgment. |
| Loops | Repeat a bounded body by count or over an input collection; expose iteration state and an explicit completion path. |
| Joins and Fuse | Wait for branch results, then select, combine, or arbitrate outcomes. Fuse adds judgment beyond synchronization. |
| Supervisor and approval gates | Approve, request revision, choose a branch, ask a person, or block progress under the configured policy. |
| Subworkflows | Call a saved graph with explicit input/output mappings and bounded nesting. |
| Delay, wait, and log collection | Represent timing, resumable waits, and selective trace collection without an unnecessary model call. |
The visual editor exposes a practical set of step templates. Additional typed nodes and advanced contract fields can be present in presets or graphs created through validated interfaces. The operating guide distinguishes visible controls from API-level configuration.
Reusable definitions, fresh runs
Run inputs can include selected tasks, a prompt, and JSON variables. Input-driven steps consume that context instead of binding the graph permanently to one task. Subworkflows provide another level of reuse: a source-audit routine or approval process can be called by several parent workflows.
Reuse does not automatically supply a schedule or a SaaS connector. A repeating automation also needs an authorized launch mechanism and the tools and data access its task requires. Those dependencies belong in the workflow’s operating design.
Chapter 04
Context, state, and evidence
Downstream agents can receive explicit evidence instead of an entire accumulated conversation. Inflara supports selected upstream handoffs, artifact keys, branch inputs, workflow variables, and bounded input sizes.
Structured handoffs
A role can emit a plan, findings, a decision, verification results, risks, blockers, or other declared artifacts. These records become inputs to later steps and routing conditions. Shared exchange files carry larger outputs when a compact inline result is insufficient.
Executable output contracts
Strict roles can declare required artifact keys, kinds, parsers, size limits, and supported JSON Schema constraints. Runner validates the actual output before accepting success. Validated files receive retained immutable versions and digests; downstream private-artifact resolution checks scope and integrity.
Strict completion receipts bind results to the authenticated Runner, run, node attempt, contract, and input snapshot. Checkpoints can support reuse of valid completed work, subject to configuration, authority, input, and invalidation checks. This is stronger than treating a worker’s “done” message as proof.
Grounding must be demonstrated
Research roles can require source reading, file writing, search, network access, or browser use. Capability availability, permission, and operational evidence are separate signals. A successful native search event demonstrates that search ran; it does not demonstrate that a source body was read or that a claim is supported.
Chapter 05
Reliability and controlled autonomy
Define success before running
Research may require a source index, a claim-evidence matrix, and an independent audit. Automation may require a validated classification and a review queue. Software delivery may require passing tests and a reviewable change set. The gate must match the outcome being claimed.
Configured verification loops can require a passing stop flag before their completion branch is reachable. Exhausting an iteration budget without that evidence is a failure. Other graphs must declare their own gates; a visually connected graph does not automatically guarantee a verified business outcome.
Give each failure an owner
Inflara distinguishes environment problems, retrieval gaps, failed tests, merge conflicts, timeouts, budget exhaustion, permissions, scope, contracts, and logic. Recovery can retry a bounded step, dispatch a repair role, reroute through supervision, or ask a person. Repeating the same failure should lead to escalation, not an unbounded repair loop.
Enforce what can be enforced
Run envelopes bound node executions, agent assignments, recovery attempts, and elapsed time. Session limits constrain provider concurrency across a workflow and its children. Token use, latency, changed files, and cost evidence inform decisions where available; they are not universal hard spending guarantees.
Permissions remain explicit
Machine-owner grants, agent capabilities, execution mode, scoped MCP credentials, and approval policies define the allowed surface. Repository executable agent configuration is quarantined until its manifest is trusted. External publication requires the applicable local permissions and workflow authorization. Human-only gates must be configured when a decision must remain with a person.
Strict capability checks fail closed when support is denied, unavailable, stale, or cannot be verified under the selected policy. Opt-in lifecycle enrollment can establish eligible native-search evidence during an explicitly authorized job; it cannot turn a denied permission into a grant.
Chapter 06
Routing, memory, and evaluation
The best model is task-dependent. A high-capacity model may be justified for synthesis or difficult review while a lighter configuration handles a narrower step. Inflara exposes worker, model, and effort choices at the role and step level.
Explainable assignment
Supervisor setup offers manual pools and automatic policies: Balanced, Highest reliability, and Lowest consumption. Automatic assignment fills unassigned pools; explicit manual assignments take precedence. Benchmark snapshots supply initial model-selection evidence, and the interface exposes freshness and fallback behavior.
Verified objective outcomes can inform calibrated routing after enough comparable observations exist. The current threshold is 20 comparable results. Sparse evidence remains in shadow, and legacy node-run diagnostics are not routing evidence. Quality, cost, and latency remain separate dimensions.
Memory with a defined purpose
Working memory is the run’s current state and artifact trail. Repository guidance can hold procedural and semantic knowledge for coding work. Terminal workflow episodes record outcomes, decisions, and failures for bounded retrieval in later comparable work. Failed attempts remain failure evidence rather than verified success lessons.
Measure a workflow, not a persuasive answer
Evaluation should compare a pinned configuration against a baseline using outcome-specific checks. Inflara’s local evaluation tooling can run agent CLIs in scratch worktrees and report regressions. A benchmark score or reported confidence value alone is insufficient to establish reliability.
| Dimension | Example measure |
|---|---|
| Outcome quality | Supported claims, correct classifications, accepted outputs, or passing task-specific checks. |
| Reliability | Verified completion rate, recovery rate, repeated failure signatures, and escalation frequency. |
| Efficiency | Elapsed time, provider usage where reported, review load, and cost per accepted outcome. |
| Adoption | Repeat usage, throughput, human time saved, and sustained use in the target process. |
Chapter 07
Three application patterns
A layered deep researcher
Start with a question and evidence criteria. Dispatch independent discovery perspectives and specialist investigations. Join findings, resolve disagreements, build a source index and claim-evidence matrix, then request an independent audit.
Design requirement: verify workers’ source-access capabilities and validate the required report artifacts. A search result is an input to evidence gathering, not its completion.
A recurring support-triage workflow
Supply a new batch of cases to the same saved definition. Classify and investigate in parallel, join results, route uncertain cases to review, and produce a validated triage packet. Keep customer-facing actions behind the required approval.
Design requirement: configure authorized data access and a launch mechanism. Record a baseline for triage time and measure accepted classifications and review effort.
A supervised software-delivery team
Scope a task, compare plans when uncertainty warrants it, implement in a controlled workspace, run verification, repair bounded failures, and gather independent review. Publish after the applicable approval and machine-owner policy permit it.
Design requirement: map the repository, select explicit test gates, preserve unrelated changes, and make branch and publication policy visible.
Chapter 08
Where Inflara fits
Model APIs, native agent harnesses, and automation platforms are useful building blocks. Their capabilities vary. Inflara adds an operating surface for coordinating native workers and repeatable agent processes across projects and paired machines.
| Question | Inflara’s contribution |
|---|---|
| How does a complex agent reason in stages? | Editable roles, branches, joins, bounded loops, synthesis, and reusable subworkflows. |
| How is the process repeated? | Saved definitions with per-run tasks, prompts, variables, and execution settings. |
| Who acts and where? | Supervisor assignments, manual or automatic role pools, and authorized Runner bindings. |
| What travels between workers? | Bounded context, typed handoffs, selected artifacts, and explicit mappings. |
| What happens when work is uncertain or fails? | Declared checks, review gates, typed recovery paths, and escalation. |
| How does this become day-to-day work? | Projects, tasks, sessions, artifacts, and conversations in a shared operating workspace. |
A native coding agent can still be the right execution worker. Its capabilities sit inside the larger workflow, alongside research, analysis, automation, and review roles. Inflara does not require every problem to become a software-development task.
Chapter 09
From a prototype to daily work
- Define the outcome. Identify the recurring problem, its baseline, allowed data, and the evidence needed to accept a result.
- Build the smallest useful graph. Choose a preset or draft with a supervisor; add parallelism and specialist review where they improve the outcome.
- Establish the execution binding. Pair the machine, verify workers and tools, configure permissions, and select a supported workspace.
- Exercise the exception paths. Test invalid inputs, missing evidence, unavailable capabilities, budget exhaustion, and human escalation.
- Measure and refine. Compare accepted outcomes, time, cost, and review effort. Change one policy or model choice at a time and check regressions.
- Make reuse operational. Save the workflow, document ownership and launch conditions, and monitor continued use and business impact.
The goal is sustained, measurable workflow use: a repeatable process with understandable limits and an accountable owner.
Implementation scope
This paper is aligned with workflow contracts, the preset catalogue, supervisor configuration, Runner execution policies, capability lifecycle, output validation, checkpoint handling, and the landing-page narrative in the October 2026 source tree.
Advanced features are capability-dependent. A source implementation or version label does not establish readiness on a connected machine. Strict output receipts, artifact-only isolation, native-search enrollment, and checkpoint reuse require compatible deployed components. The desktop Runner companion is not today’s supported public installation path.
Knowledge graphs, arbitrary enterprise connectors, universal source-access guarantees, and autonomous model training are not implied by the workflow system. Connect and validate the tools the process needs.