AINative Multi-Agent Harness is a provider-agnostic orchestration layer for building reliable, bounded, and verifiable multi-agent systems.
The harness is built primarily in Go and is designed to coordinate parent agents, child agents, specialized workers, and independent verifiers across complex workflows. It provides the execution and governance layer needed to safely run autonomous agents without tying the system to a specific LLM provider, agent framework, or model.
The core idea is simple:
Agents should be able to delegate work, but they should not be trusted to run forever or approve their own output.
The harness manages that by combining hierarchical agent orchestration with explicit budgets, concurrency-safe scheduling, independent verification, retries, persistent state, policy enforcement, and guaranteed workflow termination.
- Parent and child agent orchestration
- Specialized agent roles
- Parallel task execution
- Independent verification agents
- Bounded retry and revision loops
- Token, cost, runtime, model-call, tool-call, and recursion limits
- Concurrency-safe task leasing
- Idempotent state transitions
- Persistent workflow and execution state
- Cancellation propagation
- Failure recovery and checkpointing
- Tool authorization and risk classification
- Human approval gates
- Provider-agnostic inference
- Model routing and fallback
- Full execution telemetry and audit trails
- TypeScript SDK and Mastra integration
The harness is designed to run on top of AINative primitives:
- ZeroDB — authoritative workflow, task, execution, event, and verification state
- ZeroMemory — reusable agent memory, learned strategies, and historical context
- Agent Cloud — distributed agent execution and worker orchestration
- Inference for Agents — normalized model execution and provider abstraction
- Models API — model discovery, capability routing, and fallback
- Cloud Functions — reactive workflow triggers and event-driven automation
- Lakehouse Telemetry — execution, cost, latency, retry, and verification analytics
- ZeroTime Ops — monitoring, quotas, alerts, and operational controls
- AIKit — workflow, agent-tree, approval, and execution interfaces
- Cody CLI / IDE — development, testing, inspection, and agent-driven implementation
The harness owns the orchestration layer:
Application
│
▼
AINative Harness API
│
▼
┌─────────────────────────────┐
│ Go Harness Core │
│ │
│ Workflow Engine │
│ Task Scheduler │
│ Budget Manager │
│ Policy Engine │
│ Verification Engine │
│ Tool Gateway │
│ Event System │
└──────────────┬──────────────┘
│
Provider Interfaces
│
┌────────┼─────────┐
▼ ▼ ▼
ZeroDB Inference ZeroMemory
│
▼
Models API
│
▼
Agent Cloud
│
▼
Agent Workers
Mastra, model providers, storage adapters, tooling, and client frameworks remain replaceable.
Core orchestration code never directly depends on a specific LLM provider.
All model execution passes through normalized interfaces.
Every workflow, task, and agent runs within explicit limits for:
- Tokens
- Cost
- Runtime
- Model calls
- Tool calls
- Retries
- Child agents
- Recursion depth
- Parallel execution
No agent is allowed to run indefinitely.
A worker agent cannot approve its own work.
Completed work can be routed to a separate verifier agent that evaluates the result against the original requirements and acceptance criteria.
Verification produces one of four outcomes:
PASS
REVISE
FAIL
ESCALATE
Every workflow must eventually enter a terminal state.
Typical terminal conditions include:
- Successful verification
- Retry exhaustion
- Budget exhaustion
- Timeout
- Policy violation
- Human cancellation
- Nonrecoverable failure
The harness uses leases, optimistic concurrency, versioned state, idempotency keys, and append-only events to prevent duplicate or conflicting execution.
Agents communicate through versioned contracts rather than relying only on free-form text.
Workflow state, task state, agent outputs, verification results, tool calls, budgets, and events are all represented as structured data.
User / Application
│
▼
Parent Agent
│
├─────────────┐
▼ ▼
Worker Agent Worker Agent
│ │
└──────┬──────┘
▼
Synthesizer
│
▼
Verifier
/ \
PASS REVISE
│ │
▼ ▼
Complete New Worker
│
▼
Verifier
Each agent execution is independently budgeted, persisted, traced, and governed.
- Go
- TypeScript
- REST / OpenAPI
- Server-Sent Events
- ZeroDB
- ZeroMemory
- AINative Agent Cloud
- AINative Inference
- AINative Models API
- Mastra
The project follows issue-driven development.
Implementation work is decomposed into small, independently executable stories with:
- Explicit dependencies
- Fibonacci story points
- Acceptance criteria
- Required tests
- Definition of Done
- PRD traceability
Coding agents should only pick up work that is marked READY, has all dependencies resolved, and is small enough to execute atomically.
Workers may implement work.
Reviewers and verifier agents decide whether that work is accepted.
The development process therefore follows the same architecture the harness is designed to provide.
The project requires:
- Unit tests
- Integration tests
- Concurrency tests
- Race-condition testing
- Failure-injection tests
- Contract tests
- API tests
- End-to-end multi-agent tests
- Security tests
Go concurrency changes must pass:
go test -race ./...Target coverage:
Overall codebase: ≥ 80%
Critical orchestration: ≥ 90%
Budget/state logic: ≥ 95%
The first production milestone proves the full multi-agent lifecycle:
Parent Agent
↓
Child Agents
↓
Structured Work
↓
Independent Verification
↓
Bounded Revision
↓
Guaranteed Termination
Once this foundation is reliable, the same harness can power software engineering, research, finance, operations, sales, customer support, compliance, and other autonomous workflows across the AINative platform.
Active development.
The initial implementation focuses on:
- Core domain contracts
- Workflow and task state machines
- ZeroDB persistence
- Concurrency-safe scheduling
- Budget and termination guardrails
- AINative inference
- Agent runtime
- Parent/child orchestration
- Independent verification
- Revision and retry handling
- Tool execution
- REST API and TypeScript SDK