Skip to main content
Admin stores configuration: Agent and Team blueprints, workflow metadata, and toolkit settings. A persistent StorageDriver retains those records across restarts. It does not save active executions, conversation history, harness sessions, or workflow step functions. Use the SQLite admin walkthrough to verify create → stop → restart → run before integrating another database.

Storage backends

Install matching @agentium/core@4.0.0 and @agentium/admin@4.0.0, plus express for the router. Add the selected database client below. These factories are host integration examples: the caller mounts the returned router, protects operator access, calls hydrate(), and eventually closes the returned storage.

In-memory (development)

This is useful for isolated tests. Records disappear when the process exits; calling hydrate() cannot recover the previous process’s in-memory records.

SQLite

Install better-sqlite3@11 and supply a file path on persistent storage.

PostgreSQL

Install pg@8; pass the connection string from your host’s secret configuration.

MongoDB

Install mongodb@6; pass the connection URL your deployment supplies.
For other adapters, follow their storage guide, then pass the driver through the same storage option. Verify initialization, persistence, and close behavior for the adapter you select.

How it works

Records contain JSON configuration rather than live class instances or functions. An Agent blueprint selects provider/model, instructions, named tools, and supported settings; it is not a serialized copy of every AgentConfig field. Memory, custom hooks, harness definitions, and executable Workflow graphs need application-owned construction.

Hydration flow

Call hydrate() before accepting operator or run traffic:
A stored workflow is counted but not instantiated. Register executable Workflows in application code. An existing registry name causes Agent/Team recreation to be skipped; hydration is not a reconciliation engine that overwrites all live configuration. A missing provider, unavailable tool, invalid member name, or storage error can prevent startup. Do not accept traffic merely because some earlier entries hydrated. Inspect the error and the returned toolkit hydration failures. Make configuration changes compatible with the providers and tool library available after the next restart.

Sharing storage

Admin and manually constructed Agents may share a driver. Namespaces separate record categories; they do not authorize tenants or operators. Registering an admin Agent also does not automatically attach the admin driver to that Agent’s memory.
Stop admission and finish owned work before closing the shared driver. createAdminRouter() does not take ownership of shutting down your server, Agents, or storage. See operations.

Sensitive values

Agent/Team providerConfig and original toolkit credential values are stored in the backing driver. Public blueprint responses omit providerConfig; toolkit API masking follows catalog fields explicitly marked secret. Masking a response does not encrypt storage or sanitize arbitrary unmarked configuration fields. Use host-supplied environment credentials where appropriate, restrict database access, and choose encryption/backup handling suitable for the stored values. A toolkit-config update containing masked placeholders preserves existing marked secrets. Enabled toolkit changes affect future tool resolution; existing Agents are not automatically rebuilt.

Verify persistence

  1. Create an Agent through the operator API and retrieve its blueprint.
  2. Stop the application and close the driver.
  3. Restart with the same storage, provider registration, and tool library.
  4. Hydrate, then check both the saved blueprint and the executable registry entry.
  5. Exercise a missing-tool/provider case so startup failure is visible.
Back up and restore configuration separately from conversation or durable task stores. Move to Ship for the full application’s recovery and upgrade plan.