Skip to main content

Configuration

An agent is configured in a few layers, each with one job. You will know which layer a setting belongs in, what the defaults are, and how to see the settings an agent actually ended up with.
You need exactly one environment variable to start: LLM_API_KEY. Everything else has a local default: memory in the process, the workspace and traces in ./workspace. Every output on this page is what the code printed when it was run; the model’s wording will differ on yours.

All the layers in one agent

What each line shows:
  • Nested settings merge. Only threshold_percent was given; the other five context_management keys kept their defaults. The same holds for tool_offload, privacy_config and governance_config.
  • agent.agent_config is the full, checked configuration the agent will run with. Print it when you are unsure what a default is.
  • capture: "default" is the privacy-first record: the trace marks the model prompt not_recorded instead of keeping it. The default, "full", keeps it.
  • workspace_dir moved the agent’s files, its offloaded tool results and its traces to ./agent_data.

How it works

  • Everything is checked when the agent is built. An unknown key, a value out of range or a setting for the wrong transport raises a ValueError from the constructor, naming the setting. Nothing waits for a run to fail.
  • Code beats the environment. Environment variables supply secrets and connection strings, and defaults when code says nothing. A workspace_config in code replaces the workspace variables entirely.
  • A dict or a typed object. agent_config takes a dict, or an AgentConfig, whose fields your editor completes:

1. Environment variables

The model key

One variable, whichever provider you choose in model_config; the runtime hands it to that provider. It is read on the agent’s first run. Ollama needs none. To take the key from somewhere else, such as a secrets manager, put it in model_config["api_key"] instead. The runtime does not load .env files. To use one, call load_dotenv() from python-dotenv at the top of your script.

Memory

Session history lives in the process unless you pass a MemoryRouter. The store is chosen in code; its connection string comes from the environment.
The same store keeps each run’s durable record, so a paused run can be resumed in another process (Durable runs).
If the variable is missing, building the router raises instead of quietly keeping history in process memory: ValueError: MemoryRouter("redis") needs REDIS_URL (e.g. redis://localhost:6379/0). Set it, or use MemoryRouter("in_memory") for a store that lasts only as long as this process. "sql" without DATABASE_URL and "mongodb" without MONGODB_URI raise the same way.

Workspace

The workspace holds the agent’s files, offloaded tool results and, by default, its traces. It is separate from memory. OMNICOREAGENT_WORKSPACE_PREFIX (default workspace) prefixes the object keys in S3 and R2. The same settings in code, which replace the variables: agent_config={"workspace_config": {"workspace_backend": "s3", "s3_bucket": "..."}}. S3 and R2 need omnicoreagent[s3]. More in Workspace files.

Trace exporters

Traces are kept on local disk without any external service. To also send each finished trace to an OTLP-compatible backend, install the extra and name the exporter:
destination is otlp, langsmith, opik or jsonl. An exporter is a copy sent after the run; it is never in the run’s way (Observability).

OmniServe and background runs

You need none of these to start: the server binds 0.0.0.0:8000, exposes the background API, starts its worker and keeps tasks in memory. A variable overrides the same value passed to OmniServeConfig in code.
The task store is not the memory store: it keeps tasks, schedules, runs, attempts, leases, heartbeats, retries and cancellations. Keep the in-memory default only while trying things out; a durable store keeps background tasks across restarts. Use SQL for local durability with SQLite, or PostgreSQL or MySQL when several processes share one store. Use Redis when your deployment already operates Redis with persistence and no eviction for task-store keys. Use MongoDB when MongoDB is your durable operational store; its writes use majority write concern. Pick one backend:
More in OmniServe and Background agents.

2. Agent configuration

The settings you are most likely to change. Each has a default; leave out what you do not need. The other settings, and every nested default, are in the agent settings reference.

Which limit to use

Several settings stop a run; they count different things. max_steps is the one to set first. Budgets are the only limit in dollars, and the only one across runs. governance_config["sandbox_config"] names where the execute tool runs commands: docker, e2b, modal, daytona, vercel, http (your own service), or local (the machine the agent runs on, not isolated), plus any provider you register. none gives a policy without a sandbox; local_test runs registered handlers for tests. What each needs, and which can limit a sandbox’s network to named hosts, is on Sandbox providers.

3. Model configuration

Providers, model names and reasoning models: Models.

4. MCP tool configuration

Each MCP server is a dict in mcp_tools:
name is the server’s identity in tool routing, policy and traces. command, args, cwd and env apply to stdio; url, headers, timeout, sse_read_timeout and auth to sse and streamable_http; connect_timeout (30 seconds by default) and call_timeout to all. A setting that does not apply to the transport raises a ValueError naming the server. Every setting, OAuth and reconnects: MCP.

5. Telemetry configuration

Every run’s trace is kept without any setup. telemetry_config changes what it keeps and for how long: To share one archive of finished traces between several processes, set archive_index_url to a database and archive_target or archive_bodies_path for the bodies. All of it, with the rest of the settings, is in the telemetry settings reference; reading a trace is on Observability.

When things go wrong

All of these are raised by the constructor, before any model call, unless noted.
A misspelled or unknown key. The message ends with every valid setting. With AgentConfig(max_step=...) the same mistake is a TypeError: ... got an unexpected keyword argument 'max_step'.
A setting from 0.3. The message says what replaced it:
Nested settings are checked too, and the message lists the allowed keys:
A value out of range. Others you may meet:
Without a model: ValueError: model_config.model is required.
A stdio server takes command and args; an HTTP server takes url.
Raised by MemoryRouter(...):
PostgreSQL is MemoryRouter("sql") with DATABASE_URL pointing at it.
The store’s extra is not installed. The message names it, for example Install it with: pip install 'omnicoreagent[redis]'.
The store’s variable (REDIS_URL, DATABASE_URL or MONGODB_URI) is not set in the process that builds the router. Set it before the router is built; the store never falls back to process memory on its own, so history is not lost quietly. See the warning under Memory.

Next

Agent settings

Every agent_config key and its default, generated from the code.

Models

Providers, model names, reasoning models.

Memory

Durable stores, history windows and summaries.

Security model

Policy, sandboxes and budgets in governance_config.