About Hodman

What is Hodman?

Hodman combines an AI agent harness, cloud runtime and collaboration platform around each software project. You can build an app, run it, share it with colleagues and keep improving it with AI.

01 · Harness

The working system around the model.

A model can propose code. A harness gives it the project context and tools required to finish the job: files, shell commands, logs, database access, previews, tasks and a record of the conversation.

Why we built our own

Hodman’s agent needs to work in the same project that your team uses. The harness understands Hodman projects, runtime state, publication, tasks and permissions. It can build the first version and return later to investigate or change the running product.

You choose the model and funding source separately. The harness is the workflow and tool layer around it.

02 · Cloud

A runtime for every project.

A cloud project runs in an isolated container with its code and services. Durable project files and runtime data live on mounted storage; structured application data lives in PostgreSQL. Hodman supervises long-running services and routes the preview and published app to stable URLs.

  1. 01

    Prepare

    The agent edits the project workspace, installs dependencies and checks the application.

  2. 02

    Run

    Hodman reconciles the project services and opens the development version in preview.

  3. 03

    Publish

    When you approve a version, Hodman builds a release and serves it from the project’s production address.

A project family can contain a root app and mounted web or landing subprojects. In the current runtime they share a parent-owned container while keeping separate workspaces and task queues.

03 · Platform

Projects can use Hodman as a control plane.

Inside a current cloud runtime, a project-scoped Hodman CLI identifies the project from its credential. Project code and agents can use it without receiving a person’s account token.

Know where they are

Read the current project identity, runtime environment, canonical preview URL and production URL.

Publish and inspect releases

Request publication, check its status and read the project’s release history.

Work with tasks and conversations

List and update project tasks, read Thread messages and send auditable instructions within the permitted project scope.

Use approved platform services

Some project-owned integrations can use platform capabilities such as approved Google Drive access through the same signed project identity.

The project credential is restricted to project capabilities. It is not a user account and does not grant ambient access to every project in the workspace.

04 · App Connections

A project can expose functions to other projects.

A project opts in by providing a dedicated command-line interface with documented commands and JSON results. Another project discovers and calls it through Hodman. The platform authenticates the caller, checks an explicit connection and runs the command in the providing project’s runtime.

One implementation, several ways to use it

A CRM project can expose a command that returns pipeline totals. Its own UI, scheduled reports and an approved reporting project can all use the same business logic.

The workspace owner controls the connection

Being in the same workspace is not enough. A manager chooses which source projects may call each providing project. The current permission covers the project’s published CLI as a whole and can be revoked.

The call stays explicit and auditable

The source sends command arguments, not an arbitrary shell command or network address. Hodman verifies the grant and routes the request to the target runtime. This is a deterministic app-to-app call; it does not create another AI conversation.

The project is the common unit.

Code, runtime, data, releases, tasks and AI work stay attached to the same project. That is what lets a team build an app, operate it and connect it to the rest of its workspace.