Six levels, multiple entry points
MCP connections are configured in Galaris, with fine-grained permissions by agent, connection and function. The hub exposes the authorised catalogue to configured engines including Hermes, DSH, Codex, Claude and the internal harness. Its chat and documents are integrated solutions within this ecosystem.
The agentic OS is the software foundation organising these capabilities above your infrastructure. Galaris applications provide one interface; messaging channels and API clients can also access agents or models.
| Level | Role | Position |
|---|---|---|
| Infrastructure | Servers, compute, storage, networking and host operating system | Beneath Galaris |
| Models and providers | Ollama, OpenRouter and compatible endpoints, local or remote | Connected services |
| Model access | API gateway, inference, events, usage and available costs | Galaris |
| Agent execution | Identities, roles, missions, delegation and harnesses | Galaris |
| Shared services | Memory, skills, MCP tools, connections and permissions | Galaris |
| Applications | Conversations, goals, documents and processes | Galaris applications and external clients |
These levels describe responsibilities, not a mandatory path through every layer. A client can use the LLM gateway without running an agent; a request from Telegram or Nextcloud Talk can engage an agent without opening the Galaris interface. Janus provides a single front door for selecting an agent from a compatible client.
The channel, engine and business tool can be chosen separately: Telegram to ask, Hermes Agent to execute a task and Notion to work on pages, with the required connections.
Three layers with explicit responsibilities
Web, PWA, APIs, messaging and voice are entry surfaces. Internal control paths own conversations, Tasks, voice, Processes and Dream. Execution then uses a model, Task harness, voice provider or Process bridge. Core modules provide infrastructure; app modules own domains; bridges adapt external systems.
Keep conversation available during tasks
Conversation has its own scheduler, separate from the task scheduler. The inference worker lets each caller manage its concurrency limits: long calls do not occupy a shared queue that would hold up conversations. This separation aims to keep the exchange available during background work.
It does not preempt calls already running at a provider. Response time also depends on the model, resources and provider limits. The two agentic loops explain how to check progress, adjust instructions and request a stop through conversation.
A Task contract independent of its harness
Galaris resolves identity, objective, profile, model, effort, context, permissions and tools before execution. The driver can emit events, then exactly one terminal result. The conversation controller follows a separate path using Low-tier inference and bounded tools; it can create a Task without calling that Task’s harness.
Several harness families behind one Task interface
The internal Pydantic AI runtime and declared external harness providers implement the Task-facing contracts. Model providers remain separate bridges. This permits changing a Task execution engine while retaining its mission, memory and file identities in Galaris.
Portability requires checking capabilities
Drivers differ in checkpoint formats, isolation, supervision and supported effects. Registry presence does not establish activation or suitability. Inspect the selected driver, contract tests and effective configuration before relying on a guarantee across harnesses.
Keep authority with the right component
Task owns state, attempts, leases and scheduling; the Agent facade selects and drives execution. The harness emits events and exactly one terminal result. Messenger owns canonical conversations while bridges adapt transports.
Resources retain their Tool URI. A temporary materialisation for a library does not become durable storage. Process tracks external execution; callbacks update state without replacing a terminal result with a late event.
Integration contracts · Resource lifecycle
A shared completion and recovery contract
A final result is accepted only after the stream closes normally and cleanup completes. Missing, duplicate or subsequent events cause a protocol failure. Duration, inactivity and volume limits follow harness policy.
Each driver interprets its own checkpoints and indicates whether recovery is safe, needs reconciliation or is forbidden. Cancellation distinguishes request, confirmation and unknown outcome, with local and remote scope. Harness Manager provides diagnostics, configuration and an installation archive; downloading it does not execute a remote installation.
Media stay attached to their original message
The internal engine prepares media under the agent’s access rights, prioritising current messages and then recent history. Preparation materialises each URI only once within its byte budget and cleans up temporary files.
Inputs already supplied remain in the checkpoint and are reused on recovery. This continuity does not turn a textual URI into an implicit download or promise identical capabilities across engines.