Inside the system

01

How the agent knows the system it works in

The harness supplies project identity, instructions and available tools. The agent can read project files and memory, load relevant skills and inspect runtime state. Project code can also use the project-scoped Hodman CLI. It learns through these interfaces rather than having automatic knowledge of every connected system.

• Builder and agent profiles
• Project context, tools and on-demand skills
• Project CLI and the external Hodman Toolkit

02

A container for the project family

In the persistent runtime, the parent project and its subprojects share one parent-owned container. Mounted workspaces and data survive container replacement. Dynamic apps run as supervised services; static builds are served by the shared gateway.

• Parent and subproject workspaces
• s6 services and runtime reconciliation
• Preview, publication and routing

03

What happens after you send a task

A thread holds the conversation, while tasks and agent runs record the work and its execution state. Schedules create separate tasks. Queued input can wait for the next response or steer the agent at a safe boundary between tool execution and its next model request.

• Conversations, Kanban and execution state
• Schedules and their individual runs
• Message queue, steering and follow-up

04

Where code, data and memory live

Project files hold the application and its human-readable knowledge. PostgreSQL stores structured application data. Runtime storage holds uploads and generated artifacts. Project memory keeps useful context and decisions so the agent can read them in later tasks.

• Workspace and durable runtime storage
• Application data and files
• Knowledge notes and context between tasks

05

One integration used by people and agents

An integration’s business logic lives in its project. A protected UI, an application API and an operational command can use the same implementation. App Connections lets another explicitly authorized project call a dedicated command interface without taking ownership of the provider credentials.

• Shared logic behind UI, API and CLI
• Project-owned credentials and connection state
• App Connections and explicit grants

06

Who can act and who pays for AI

The workspace groups people, access policies and shared components. Project credentials have their own scope; membership does not automatically connect every project to every other one. AI funding is resolved separately through a project override or the workspace default, with platform Credits used when neither is configured.

• User access and project identity
• Workspace defaults and project overrides
• AI usage versus the workspace subscription