Inside a Hodman workspace

Start from a description, bring an existing repository or upload project files. The Builder UI keeps the conversation beside the project you are changing. Ask for a change, inspect what the agent did and open the application in preview without assembling a separate environment for every experiment.

A project gives the agent tools to read and edit files, run commands, inspect logs and work with its database when configured. You can follow the work, review the output and ask it to check the result. The preview is a working application, so you can test a form or a complete user flow rather than judge a static mockup.

Working changes and the published version are separate. Review the preview before publishing, then continue improving the same project with feedback. Sharing the workspace lets teammates participate in its tasks and conversations; people using the published application do not automatically become workspace members.

Split a site or application into subprojects so different teammates can work on different parts. Each subproject has its own workspace, tasks and development cycle. In staged publishing, each also has its own preview and publication cycle: review a change and publish that subproject when it is ready, without waiting for the rest of the site to be finished.

Subprojects do not count as additional projects toward your workspace plan’s project allowance. You can give each landing page or application module its own development and release cycle while keeping the family within one top-level project slot.

For example, keep the admin panel and analytics backend in the parent project. One colleague develops a campaign landing page in a subproject, while another updates a different landing page. Each can review and publish their part separately. The pages can send visits and leads to the same backend, so the team compares results in one dashboard. That reporting needs to be built and configured for the experiment.

In the persistent runtime, the family shares one parent-owned container. Subprojects keep separate working directories; dynamic apps run as separate services, and static pages use the shared gateway. They share CPU, memory and storage, so separate release cycles do not mean separate infrastructure or unlimited resources. Coordinate changes to a shared backend or API when other subprojects depend on it.

Each project has a task board. A task has its own conversation and result, so a new question does not have to become another paragraph buried in the same long chat. Open a card to see its context, the agent's work and what still needs review.

Use Backlog for work you want to record without starting it. Move ready work to To do when it should be picked up. The scheduler starts eligible tasks when the executor is available; In progress shows active work, and Done holds completed tasks. Inbox is the conversational entry point rather than a second work backlog.

You can plan the next changes while keeping the current task focused. Review the output in the task's thread and, where appropriate, in the application's preview. Completion can be handled by a person or by the task's configured completion policy; a card reaching Done is not a substitute for your product's release checks.

Choose an AI-agent project when the ongoing workflow is the main result. Give it a purpose, project instructions and access to relevant tools. It can investigate a question, prepare a report or work on a connected application, using the same task and project context when you come back.

Integrations belong to the project that implements them. Connect company documents, a CRM or an internal API with the access you approve. Existing project integrations can be reused through App Connections, so another agent does not have to repeat the same connection setup. An agent project does not come with automatic access to every company system.

The agent can plan steps, use tools, check output and ask for missing input. Accepted decisions and working rules stay in project memory. Use scheduled tasks for recurring work and follow-ups when a workflow needs another check. Review customer-facing actions and sensitive access before allowing them.

A colleague can work with the agent through the web workspace or a configured conversation in Telegram, Slack, Microsoft Teams or Mattermost. They can ask a question or reply with feedback in chat, then open the web UI when they need the task board, files or a preview.

A workspace has a Skills & MCP catalog separate from any one project. Upload a trusted component archive, review the AI-assisted analysis and publish a version for the workspace. Administrators can manage custom components and decide which built-in skills remain available.

A skill gives the agent instructions for a particular kind of work and can include supporting scripts or a CLI. Attach the relevant component to a project instead of copying the same instructions into every conversation. Versions can follow the latest published release or be pinned when a workflow needs a stable setup.

Installation and execution happen inside the project's persistent runtime. Keep secrets out of the archive: workspace-level environment settings provide a baseline, and project overrides supply the values needed for that project. Preparing a component can install dependencies and run its approved commands, so only upload code you trust.

MCP components can also be uploaded, prepared and managed as project services. That lifecycle is distinct from exposing their tools to the agent: direct MCP tool discovery and invocation in the agent loop are still being completed. Do not assume an uploaded MCP server is already callable by the model.

Suppose one project already reads the CRM and serves a dashboard. Another agent needs those same figures for a weekly report. App Connections lets it call commands deliberately exposed by the first project, while the integration credentials stay with that project.

The owner prepares a project connector with a documented command interface. A workspace manager authorizes which source projects may use it. The receiving project runs the requested command and returns its result; the connection itself does not need to open a new AI conversation to route each request.

Access is explicit and revocable. The current grant covers the connector's whole published command set rather than permissions for each individual command. Expose a focused interface for the intended business operations, not an unrestricted shell or administrative command surface.

The target project can run on a different host, including an approved on-prem execution host. It does not need a public business API just to receive a connector call. Results still return to the caller, so local execution does not by itself keep returned data out of the hosted conversation or AI context.

In the web chat, you can send another text message while the agent is working in the same thread. It is saved in the message queue as Next message by default. The current response can finish, and your next request remains available to continue the conversation.

Open the queue counter near the chat input to inspect pending messages. The popup shows their text and delivery mode. Remove a pending message if you no longer need it, or choose Current cycle when it should guide the work already underway.

Current cycle is steering. The agent receives the message at the next available boundary after the current batch of tool calls and before the next model request. It does not rewrite a model request already in flight, cancel a command that has started or undo work already performed. If that boundary is no longer available, the input remains available for the next run.

Use Next message for a separate follow-up task. Use Current cycle for a correction that should influence the ongoing task, such as which file to change or which result to check. Queued messages currently support text, not file attachments; attach files when the normal send flow is available.

The Hodman workspace plan and AI usage are separate. The plan covers the service and its project and team allowances. People using the applications you publish are not automatically members of the workspace. Hosting your own runtime also leaves server and infrastructure costs with you.

Choose a supported ChatGPT subscription, an OpenAI API key or platform Credits as the AI funding source. Set a workspace default for projects to inherit. When a project needs a different source, an authorized manager can configure a project override. The project setting takes precedence over the workspace default.

This lets you connect your own supported subscription for an agent that colleagues use. They work with that project through the selected source rather than each needing to configure an AI payment method for it. The provider's usage limits and account conditions still apply; connecting a subscription does not make AI usage unlimited.

Platform Credits are a separate balance used when selected as the source. A disconnected or exhausted external source requires attention; do not assume it silently switches to paid Credits. Check the effective source in project settings before starting expensive work. Some capabilities have their own funding requirements: transcription, for example, uses a configured OpenAI API key or platform Credits rather than the ChatGPT connection.