Imagine a claims batch with 200 document packets: claim forms, clinical notes, and supporting billing documents. Take packet 37. Its itemized bill is missing, and the checklist for this example requires that bill before the packet can be marked complete.
A document-review agent needs to find the gap. A claims-review agent needs to carry that finding forward. A communications agent may need approval to request the missing bill. Later, when a reviewer asks whether the packet is complete, the assistant must distinguish “we requested it” from “we received it.”
The engineering challenge is keeping those distinctions intact as work moves between agents, tools, and people. Here is how Agent Workspaces in KORA, Actava.ai’s platform for building and running agents, approach that problem.
The short version
An Agent Card defines a specialist’s instructions, model, tools, skills, and controls. An Agent Workspace connects specialists into a workflow, with shared files and recorded progress. A Handoff tells the next step what was established, what remains unresolved, and where to find the evidence.
The work continues across a handoff; each specialist receives its own configuration. Human approvals govern configured actions. For supported read-only answers, an Evidence Ledger supplies runtime observations to Mandatory Checks, and a Release Barrier withholds the draft until the checks accept it.
A workspace keeps the work addressable
An Agent Workspace defines the orchestration. Each execution also has a scoped working area: inputs, step directories, a progress index, and the artifacts its agents produce.
For packet 37, Document Review might write facts.json, sources.json, and missing-items.md. The last file records the absent itemized bill. Claims Review can inspect that note, locate the source material, and produce its assessment. These filenames are illustrative; the runtime indexes the actual outputs.
A multi-step Agent Card can also divide its own procedure into sections. The runtime records the plan’s hash, current section, last completed section, and pending Handoff. Position in the workflow is explicit state, separate from the agent’s current conversation.
This matters when a procedure outgrows the model’s working context. Large tool results can move into artifacts, leaving a compact preview and a path. Older history can be compacted while detailed findings remain available through files. The next specialist can start with the missing-items note and retrieve the underlying evidence when needed.
File access is scoped to the execution; parallel row work can be narrowed further to its assigned files. Sharing a workflow does not give every agent access to every run.
Orchestration decides who works next
The claims batch has a known sequence: load records, review documents, assess completeness, and handle missing items. An Agent Workspace can compose those steps, fan out across records, and aggregate upstream results. Batch settings and organization limits bound concurrency.
A conversation orchestrator can invoke a selected specialist or an entire Agent Workspace, wait within a defined budget, and return its result. Progress events identify the child run. Completion, failure, and a pause for human input have distinct return states. If the wait expires while work continues, the caller receives a “still running” status.
Interactive dispatch allows one active child at a time per conversation. Batch fan-out has its own bounded parallelism. This gives the reviewer a conversational entry point to the claims batch while the Agent Workspace owns its sequence and progress.
At a handoff, replace the active configuration
When Claims Review takes over packet 37, it needs the extracted facts and source references. It does not need Document Review’s ability to write extraction artifacts.
At transitions between text agents, the runtime replaces the preceding Agent Card’s configuration with the next card’s configuration. Tools, skills, knowledge scopes, model selection, verification policy, and approval requirements have explicit transition behavior. Unset agent-owned fields are cleared. Run-owned state—identity, progress, and artifact locations—continues.
This is what makes a specialist reusable: its authority comes from its own configuration, independent of the agent that ran before it.
Tools make this boundary extensible. Structured inputs and results let customers connect their retrieval systems, document processing, and business actions. A claims-lookup integration can change behind its contract without changing the document-review procedure. Skills supply reusable instructions for working with those capabilities.
Large catalogs bring a context cost. Deferred tools can begin as a compact index, with detailed schemas loaded when searched for. Attached skills similarly load full procedures when needed. Loading a schema changes what the model sees; it does not grant new access. Capability selection, organization permissions, identity checks, and configured approvals govern execution.
In this example, the outbound request belongs to a separate Communications Agent Card. That card receives the request tool and its approval requirement explicitly.
Pause at the action that needs approval
The Communications agent proposes requesting packet 37’s missing bill. Before the configured outbound tool executes, tool approval pauses the call and presents the proposed action for an approve-or-reject decision.
KORA also supports approvals on planned tasks. A task approval attaches a reviewer group to a task and pauses its recorded transition. A tool approval intercepts the selected call before its handler runs. For the outbound request, the tool boundary is what prevents execution before approval.
The pending decision is recorded with the run. Approval can resume the waiting action; rejection keeps it from executing. An orchestrator waiting on that run receives a paused status, returning control to the conversation while the person decides.
Check the answer against the evidence
Later, a claims reviewer asks whether packet 37 is complete. The application’s approved retrieval integration exposes the prepared evidence to a separate read-only assistant interaction.
Mandatory Checks can examine the request before execution and the proposed answer before release. The Evidence Ledger contains runtime observations: retrieval receipts, available facts, source references, tool activity, and the exact private draft. Receipt identifiers come from the runtime; printing plausible JSON cannot establish one.
Suppose the draft says “the packet is complete,” while the evidence still shows no itemized bill. A configured completeness check blocks that answer. The Release Barrier keeps the draft private and returns a controlled response: a safe fallback stating what could not be verified.
A successful retrieval with no records, a failed retrieval, and a numeric zero remain distinct in the check contract. That distinction prevents a technical failure from masquerading as a business fact.
Checks can use deterministic rules, custom code, or a bounded model judge. Reviewed checker bundles are pinned by content hash and verified before execution. Script checkers run with restricted file access, no network, and resource limits. Model judges receive declared evidence inputs and have no tools. A configured post-check can allow one answer-only rewrite using existing evidence, followed by another pass through all post-checks.
Follow packet 37 through the system
Start the batch. A conversation orchestrator invokes the configured Agent Workspace. Its dispatcher assigns packet work within concurrency limits.
Find the gap. Document Review records the missing itemized bill and source locations in its Handoff.
Change specialists. Claims Review reads those artifacts with its own tools and checklist. The preceding agent’s write capability is cleared.
Ask before acting. Communications proposes an outbound request. Its selected tool waits for approval. An approved request authorizes sending; it does not establish that the bill has arrived.
Answer the reviewer. In a later read-only request, the assistant retrieves the packet evidence. If it drafts an unsupported completeness claim, the check blocks it and the Release Barrier returns the fallback.
Keep the case as a test. Save the missing-bill scenario so future changes must preserve that distinction and produce an evidence-supported answer.
Each boundary leaves something concrete to inspect: output files, active configuration, a pending action, a retrieval receipt, or a check result.
Agents can help build other agents
Once specialists have explicit configurations and tools, authoring them becomes structured work too. The Actava.ai builder is an agent with authorized authoring tools: it can find existing agents, inspect the capability catalog, create a draft Agent Card, and update its instructions, plan, model, tools, and skills. With the necessary permissions, it can also create voice-agent drafts and assemble Agent Workspace steps.
For our example, an authorized user could ask it to build the Communications agent, select an available document-request tool, and configure the appropriate approval group. The builder discovers actual capabilities and groups in the organization. A missing connector remains a setup requirement.
These tools use the same authoring APIs as the platform’s editor. The conversation and editor work on one draft, with role and organization checks enforced at the API boundary. Conversational changes remain visible and editable after the conversation ends.
The draft can then be tested, refined, and submitted through the existing review workflow. Publishing requires the appropriate approval authority. The result is a reusable specialist that fits into the same execution model we just followed.
Why we chose these boundaries
Why use artifacts instead of keeping everything in context?
Artifacts keep detailed evidence addressable as the conversation grows. The cost is designing useful Handoffs: clear facts, source pointers, and unresolved questions. Downstream agents also spend tool calls retrieving detail. A compact summary alone is insufficient when the next decision needs an exact source.
Why replace configuration instead of inheriting it?
Inheritance makes a specialist depend on its predecessor. An omitted tool or approval field could leave an earlier capability active. Replacement makes each Agent Card responsible for declaring what it needs. The cost is more explicit configuration, including capabilities that several specialists share.
Why block when a checker fails?
A missing checker, timeout, or malformed verdict provides no valid acceptance decision, so it blocks release. That can withhold a correct answer during a checker outage and adds latency. We accept that availability cost for a workflow that has made the check mandatory.
Why is the Release Barrier read-only?
An answer can be withheld; an external action may already have happened. The current profile excludes shell access, writes, delegation, and unsupported tools. Connected tools must be explicitly classified as read-only, and their integrations must honor that classification.
The cost is a deliberate composition limit. Mandatory Checks currently refuse later Agent Workspace steps and paused-turn resumes; a checked turn also cannot pause for task approval. Action flows use their separately supported approval controls. That is why packet preparation and the later checked answer are separate interactions in this example.
These controls support compliance requirements. Whether a workflow satisfies a particular requirement also depends on its configuration, deployment, and connected systems.
Under the hood: recovery and testing
Persistent checkpoints retain an agent’s working state when configured, while execution records track progress and pending decisions. Orchestration ownership uses a database lease: a worker can claim an unowned run or one whose lease has expired, and renewals and releases must match its owner. Recovery can reclaim orphaned work within configured execution-age limits.
A saved pause preserves the decision needed to continue. A recovered run still needs to reconcile external effects: a connected system may have accepted a request before the connection failed. Checkpoints and leases do not supply universal exactly-once delivery; action integrations need appropriate deduplication and reconciliation.
Security follows the same boundaries: organization and role checks on resources, identity checks on protected tools, approval on selected actions, and scoped file access. When configured, checkpoint protection encrypts detected PHI in supported message content. Private check inputs and withheld drafts stay out of the Mandatory Check path’s logs.
Tests can isolate a single check with supplied evidence or exercise a whole read-only interaction through retrieval, reasoning, and answer release. Whole-agent scenarios use the answer or fallback actually released as evidence of the result. Saved scenarios capture the configuration and its digest, so later edits cannot silently substitute a different configuration. External data and model outputs can still vary.
Choices you can borrow
- Make results addressable. Give the next specialist a small Handoff and a path to the detailed evidence.
- Replace authority at transitions. Preserve execution state while loading each agent’s declared configuration.
- Separate decisions from observations. Record human authorization and the evidence of what happened as distinct facts.
- Test what reaches the user. Evaluate the released answer or fallback, alongside the checks that govern it.
- Make generated agents ordinary artifacts. Give them the same editor, tests, and release process as manually authored agents.
Bring a workflow to an Actava.ai demo, or explore CHI-Bench for the healthcare tasks behind our benchmarking work.
