Skip to main content
@agentium/harness is Agentium’s execution and composition package. Use it when your application needs to decide which tools and models a run can use, enforce shared budgets, compose reusable capabilities, or manage resources across runs. An Agent, Team, or Workflow comes from @agentium/core. A driver connects it to HarnessRuntime. The runtime owns the session, grants, events, cancellation, and cleanup; the driver performs the work through controlled execution services.
This section targets @agentium/harness@4.0.0 with matching @agentium/core@4.0.0. See installation or migration from Agent-owned harness configuration.

Run your first harness

Start with a runnable local example, then connect a model-backed Agent.

API reference

Every public export, configuration type, and method signature.

​
How the pieces fit

​
Build a complete application

Research with a tool

Combine source context, a lookup tool, grants, budgets, and streamed events.

Continue a conversation

Reuse history, inspect snapshots, isolate users, and release sessions.

Review workspace files

Give a run explicit file context and clean up an owned workspace.
Each recipe includes installation, a complete source file, a run command, expected output, and failure handling. See examples for the other application paths.

​
Choose the right entrypoint

Use @agentium/harness for the runtime, abilities, drivers, policies, manifests, and watches. Use @agentium/harness/testing for testDriverContract. You can still use a plain Agent directly when its own run loop is all you need. Core consumes the neutral ExecutionServices interface; it does not construct a harness. See migrating to the package if you previously used Agent-owned harness configuration.

​
What the host owns

Your application authenticates callers, supplies identity and grants, connects services, and chooses model providers. An identity field scopes state; it does not authenticate a request. Custom abilities and drivers are trusted application code. HarnessRuntime currently executes locally. Its default sessions, event history, and artifacts are in memory. It does not resume interrupted model runs after a process restart. DurableWatch is a separate lifecycle with explicit durable store, scheduler, and notification connector requirements. Continue with the quickstart, or use the troubleshooting and testing guide while integrating a custom driver.