Skip to content
Kiberon LabsAgentic Engineering Ebook

Harnesses

Harnesses are obviously a core part of how the Ikidna system is intended to operate as they form the core runtime/

From the Orchestrator’s perspective, harnesses are interchangeable provided they are accessible via a conformant ACRI driver. ACRI (Agent Container Runtime Interface) is the standard interface contract that decouples the Orchestrator from any specific harness implementation, in the same way that CRI decouples the Kubernetes kubelet from any specific container runtime. Each harness is evaluated on its own merits; ACRI is what makes routing between them operationally tractable.

Requirements

Section titled “Requirements”

Ikidna agents are preferred to run inside containers as part of an orchestrated system, not on a developer’s machine. That context shapes what matters in a harness.

  1. Ability to spawn subagents. Harnesses must support delegation an agent should be able to spin up a subordinate agent for a scoped task and receive its result. This is necessary for any multi-agent execution model, and improves performance significantly by helping to prevent context from overwhelming a single agent and forcing complex compaction.

  2. Standards compliant. Preference for harnesses that implement open standards (MCP, OASF, etc.) rather than proprietary tool interfaces. Standards compliance is what makes the tool layer interchangeable and the system composable.

  3. Agent-first, not human-first. The harness runs in a container. There is no user at a terminal. A rich TUI or interactive UX is irrelevant, what matters is a clean programmatic interface, predictable output, and reliable headless operation.

  4. Extensibility and access to tooling. The harness must be able to integrate with external tools, context systems, and services without requiring the agent to leave the execution environment. Custom tool registration and MCP server support are the minimum bar.

  5. Observability. Execution traces, tool call logs, and agent decisions must be inspectable. In an autonomous system, observability is what makes debugging and auditing possible. A harness that cannot be observed cannot be trusted in production.

  6. Security and sandboxing support. The harness should support or be compatible with sandboxed execution restricting filesystem access, network access, and command scope to what the task requires. This is a prerequisite for running autonomous agents safely.

  7. Strong benchmark scores on OpenBench. Benchmark performance is used as a proxy for how reliably the harness translates model capability into correct task execution. A harness that consistently underperforms on structured benchmarks is a liability regardless of what model it runs.

  8. Broad model support and multimodality. The harness must not be coupled to a single provider. Ikidna routes tasks to different models based on cost and capability; the harness must support that routing without friction, including multimodal inputs where relevant.

  9. Open source. OSS is a hard requirement. Vendor-controlled harnesses introduce lock-in, limit auditability, and cannot be adapted to Ikidna’s architecture. The harness must be forkable and inspectable.

  10. Structured workflow support. Not every task should be left to the agent’s discretion. The harness must support constrained execution modes where the step sequence, tool usage, or output format is fixed by the orchestrator. This is necessary for high-stakes or compliance-sensitive work where freeform agent behaviour is not acceptable.

  11. A strong Agent-Computer Interface. Much of a harness’s real-world capability comes not from its model support but from the quality of the interface it presents to the agent windowed file views, lint-on-edit guardrails, concise structured tool output, and reliable edit formats. A strong ACI is in large part what high benchmark scores (requirement 7) are measuring; evaluate it explicitly rather than treating benchmarks as the whole story.

Archived Notes

Section titled “Archived Notes”