A workspace where AI agents can work.

What is HELLO OS?

HELLO OS is an experimental agent workspace and runtime project. It gives developers a place to examine building blocks that are often scattered across scripts, model clients, local databases, tool servers, and dashboards. The project connects those pieces behind one interface: a browser dashboard for people, a persistent application layer, and service endpoints that agents can call.

The name “agentic OS” describes the project direction, not a replacement for a computer’s kernel or a general-purpose desktop operating system. HELLO OS runs as an application on a machine you control. Docker Compose is the documented quick-start path; the repository also contains source code for people who want to inspect or change the implementation.

At a high level, the prototype explores four practical questions: How does an agent present an identity? How can it retain useful context between tasks? How can a tool be exposed in a structured way? How can a person understand what the agent is doing? These are connected product surfaces, not a claim that one platform solves every agent deployment problem.

In practical terms, an agent operating system prototype provides a boundary around agent-specific records and actions. A human starts or configures a workspace, a connected agent calls the methods that are available, and the application stores state so activity can be reviewed. The shape of that interaction is more important than a slogan: developers can inspect which service owns a method, where a record is persisted, and which interface a human can use to learn what happened.

Why build a self-hosted AI agent workspace?

Agent experiments often begin as a prompt and a model call. They become harder to reason about when a project adds tools, long-running tasks, shared state, credentials, retries, and human review. A workspace makes those surrounding concerns visible. Instead of treating an agent as a single chat response, HELLO OS gives the experiment a place for identity data, memory records, tool methods, task state, and activity inspection.

Self-hosting lets a developer run the prototype in their own development environment and inspect the repository before use. Local-first describes the intended deployment and data-control model: the documented setup runs on the operator’s machine or server. It does not mean every dependency is offline, every secret is automatically protected, or all information can never leave the host. Operators must review configured integrations, network access, logs, and environment variables for their own setup.

The goal is useful for developers evaluating agent architecture, building a proof of concept, studying an MCP-compatible tool server, or learning how task APIs and memory layers can fit together. It is not positioned as a managed cloud service, a fully autonomous employee, a secure secrets vault, or a finished enterprise control plane.

A local agent workspace can shorten the feedback loop during development. You can change the app, restart the local services, and observe how the new behavior changes the dashboard or an API response. That makes it easier to ask concrete questions about agent software: Is context stored in a predictable place? Can a task be cancelled? Is a tool’s input visible? Can a reviewer tell the difference between a result from memory and a new external response?

Agent workspace features at a glance

How the HELLO OS architecture fits together

The project uses a web application architecture rather than a custom operating-system kernel. The Next.js application provides the human interface and application routes. SQLite supplies local persistence for prototype records. An MCP-compatible service offers structured methods to connected tools and clients. The agent card and task methods expose an A2A-style way to describe the agent endpoint and interact with tasks.

Each component has a distinct responsibility. The dashboard helps a human inspect and use the workspace. The persistence layer gives the prototype state across application actions. Tool methods provide bounded operations that clients can invoke by name. Task methods represent work as records with state transitions. This division makes it easier to investigate where an action is initiated and what interface is responsible for it.

“Compatible” and “style” are deliberately precise. The MCP service is implemented as an MCP-compatible JSON-RPC surface, and the task interface follows an A2A-style shape. The project documentation does not claim complete certification or full conformance with every version of either protocol. Check the current Agent Guide and source before relying on a particular method or field in another application.

HELLO OS also includes an AML compiler endpoint and MCP tool for static parsing and validation. The current validator checks text and reports static findings; it does not deploy code, execute arbitrary programs, prove that a workflow is safe, or authorize a real transaction. Treat all outputs as development assistance and review generated or validated content before use.

A useful way to evaluate the architecture is to trace one operation from beginning to end. Identify which user or agent initiated it, which route or tool accepted the request, which validation was applied, where the result was written, and what the dashboard shows afterward. If any of those steps cannot be answered from the current code, record the uncertainty before extending the system. That method is valuable for prototype evaluation because it focuses on observable behavior rather than an architectural label.

Agent identity: keys, identifiers, and human context

Identity is a central design surface in an agent workspace. HELLO OS prototypes Ed25519 key material and did:key identifiers alongside a soul record and wallet entry. Together, those elements let a project experiment with representing an agent as more than a temporary process name. A stable identifier can help a user connect an agent’s tasks and stored context to a visible record.

This identity feature should be read as an application prototype, not as a complete decentralized identity system. The existence of a DID-shaped identifier does not independently establish legal identity, trustworthiness, authorization, reputation, or ownership. A key proves control of that key under the relevant cryptographic conditions; it does not make an agent’s claims true or its actions safe.

Key handling deserves special attention. The documented prototype server stores private signing keys, which is appropriate only for experimentation after you have reviewed the code and environment. Do not place valuable production credentials in a test deployment. Production use requires an explicit threat model, secure key custody, access control, rotation and recovery procedures, and an independent security review.

The human-readable identity record matters too. A person should be able to understand what an agent is intended to do, which tools it can use, and what permissions surround those tools. HELLO OS provides a place to explore these ideas, but each deployment still needs the operator to define practical access limits and oversight.

Agent memory and context that persists

Long-running agents need a way to retrieve context from earlier activity without treating every previous message as equally relevant. HELLO OS organizes prototype memory into CORE, RECALL, and ARCHIVE tiers. These names describe a basic retrieval model: keep a smaller set of frequently useful context, retrieve relevant prior records as needed, and retain older material separately where the workflow calls for it.

The implementation also uses expiry information, valid-time filters, and retrieval budgets. Expiry lets stored information have a planned lifetime. Valid-time filters help distinguish when a fact was meant to apply. Retrieval budgets limit how much context is pulled into an operation. These ideas help make memory behavior more inspectable than an unbounded conversation dump, while leaving product-specific retention decisions to the developer.

Persistent memory can contain sensitive information. Before storing user or business data, decide what should be retained, for how long, and who can access it. A local database is still a database that needs backups, permission controls, deletion procedures, and protection from other processes on the host. “Local-first” does not remove those operational responsibilities.

For developers, the interesting question is not simply whether memory exists. It is whether retrieved records are relevant, current, and traceable to a source. Memory can become stale or contradictory; agent behavior should treat recalled content as context to evaluate rather than unquestionable truth. Inspect the current schema and memory routes in the repository before integrating an application.

A practical memory policy should define what becomes a durable record, what is temporary, and how to remove or correct an outdated fact. Keep provenance where possible: the application should make it clear whether a statement came from a user, an agent summary, or a tool result. When two records disagree, do not let an old memory silently override newer evidence. Those are implementation and product decisions that a self-hosted operator should make explicit.

MCP-compatible tools for structured agent actions

The HELLO OS tool service exposes a JSON-RPC interface described as MCP-compatible. The repository’s tool groups include forge, cortex, memory, and checkpoint operations. Structured tools give an agent a named operation with an input shape and result, making the boundary between a model decision and an application action easier to review than arbitrary shell access.

An MCP client can use a tool interface to discover or invoke supported operations, subject to the implementation and deployment configuration. Tool names alone do not grant permission. A production system still needs authentication, authorization, input validation, rate limits, audit records, and explicit rules for actions that can modify data or reach external systems. Confirm which tools are enabled in the current revision before connecting a client.

HELLO OS is useful as a place to study tool-server integration and the relationship between a human workspace and an agent tool surface. It does not imply that every model provider is built in, that a particular model is bundled, or that all tools work without configuration. Model access, external integrations, and credentials depend on the actual application configuration you choose.

Read the agent integration guide for currently implemented methods and examples. Treat the source as the authoritative reference for exact request fields, response shapes, and error behavior because a prototype can change as its APIs evolve.

When adding a tool to an agent system, define its purpose narrowly. Describe the inputs in language a person can understand, reject malformed values, and return results that communicate whether the operation succeeded. Consider what a tool could affect if an agent calls it repeatedly, with stale context, or after a misunderstanding. A tool interface makes the action explicit; it does not guarantee that the model will choose a good action.

Tasks, missions, and agent-to-agent workflows

HELLO OS includes an agent card and A2A-style task methods for sending, listing, updating, and cancelling task records. A task-based interface gives a workflow a recognizable state and identifier, which helps humans and other services reason about progress. It can be easier to inspect a task record than to infer status from a stream of unstructured messages.

The project describes these interfaces as A2A-style. That wording signals a design direction and familiar interaction pattern; it is not a declaration of complete A2A protocol compliance. Use the current agent card and API implementation to check the supported discovery and task behavior before connecting a separate agent framework.

For an experimental workflow, an operator might ask an agent to break down a research task, call a bounded tool, store a useful result, and present a summary for human review. The task surface gives the application a place to record this work. It does not mean that the agent can safely complete a high-impact operation without a person or that task execution is guaranteed to finish.

Good task design keeps work understandable: use a clear objective, define expected outputs, constrain tool permissions, set a timeout or stop condition where appropriate, and make it possible for a person to inspect or cancel the task. These are general engineering practices for agent applications, not automatic safety properties of the prototype.

For multi-agent experiments, start with a small, visible handoff. State what one agent should produce, what another agent is allowed to consume, and how a human can intervene. A task record can carry status between services, but it cannot resolve conflicting instructions or guarantee that two agents interpret a goal in the same way. Keep an audit trail of meaningful state changes and avoid granting broad permissions simply because tasks can be passed between agents.

How to run HELLO OS locally

The fastest documented start is Docker Compose. Install Docker Engine and Docker Compose (or Docker Desktop where appropriate), then clone the public repository and start the services. The browser dashboard is exposed locally on port 3000, while the MCP service is available on port 3030 according to the project setup guidance. Review the compose file and environment configuration before exposing any service beyond your machine.

git clone https://github.com/CodesbyFebin/Hello-OS.git
cd Hello-OS
docker compose up --build

When the application is ready, open http://localhost:3000. Keep the terminal open to observe startup output. Use Ctrl+C to stop the foreground compose run. The getting-started guide covers the current setup, source development, configuration, local data storage, and safe shutdown notes.

Developers who prefer to work from source can inspect the repository’s package scripts and runtime requirements. Do not assume that a command in an old blog post matches the current branch. The source repository is the canonical record for the version you have cloned; pin a commit or release when you need reproducible experiments.

If you want the prebuilt-platform story, consult the downloads page. At present, the documented quick start is source plus Docker Compose. There are no published native Android APK, Windows EXE or PEXE, or Debian DEB artifacts linked as supported installers. Avoid downloading unofficial binaries that claim to be HELLO OS releases.

After startup, take a moment to inspect the application in a low-risk environment. Confirm which ports are exposed, where persistent data is written, and how the app behaves after a restart. These checks help you understand the local deployment before connecting an external model or using non-test information. If an update changes the compose file or environment variables, read the change before recreating the containers.

Supported setup paths and platform availability

Platform compatibility here refers to running the application in a suitable Docker or source environment. It does not claim that a native app has been tested on every release of each operating system. If your environment differs from the guide, open an issue with its OS version, Docker version, command output, and a minimal reproduction.

We keep availability explicit because “download” can mean different things: source code, a container image, a script, or a native installer. Use the downloads guide to distinguish those options and verify that an artifact is actually linked to a project release. A package format should not be treated as supported until it has a reproducible build, release notes, and installation instructions.

Local-first deployment, privacy, and data ownership

Running an application on infrastructure you control can give you more visibility into where application data is stored and which network connections are made. HELLO OS is designed as a local-first prototype, and its application persistence uses SQLite. These facts make the project easier to inspect locally; they are not a blanket promise that data never leaves your host or that the installation is private by default.

Network behavior depends on the configuration and any integrations you add. If an agent calls an external model provider, API, package registry, or service, information included in that request may leave the machine. Review code, environment variables, Docker networking, logs, browser traffic, and third-party provider terms before using sensitive data. The safest assumption for an unreviewed prototype is that you should use synthetic or low-risk test data.

For local data, understand where the SQLite file and Docker volumes are stored, how they are backed up, and how to remove them. Backups can preserve information after deletion from the active database. If multiple people can access the host, account for filesystem permissions and container access. Your deployment policy should define data retention, incident response, and who can administer the machine.

The project’s goal is to make agent primitives inspectable, not to replace your organization’s privacy review. Before a team adopts an agent runtime, map the data flow, classify information, document external processors, and test what happens when a user asks to export or delete their records.

Local-first software is most useful when the operator can answer basic data questions without guessing. Know which files are created at startup, whether application logs include prompt or tool content, what is copied into backups, and whether a process running inside a container can access host files. Use the least data needed to test a workflow and remove temporary records after the experiment is finished.

Security boundaries and responsible evaluation

HELLO OS is experimental software. It is not described as a hardened production control plane, a secrets manager, a compliance-certified service, or a safe environment for untrusted autonomous execution. The current demo server stores private signing keys. This is a clear signal to treat the project as a learning and development prototype until key custody and the wider threat model have been reviewed.

Before you run the project, inspect the compose file, scripts, dependency definitions, API routes, filesystem mounts, exposed ports, and environment variables. Avoid running it with broad host privileges. Do not expose development endpoints to the public internet without authentication and an explicit security review. Never paste valuable private keys or production credentials into an experimental setup.

Before production use, an engineering team would need to evaluate authentication, authorization, tenant separation, key isolation, secret rotation, input validation, network egress, dependency risk, audit logging, backups, deletion, monitoring, and incident handling. The correct requirements depend on the application and data involved. This landing page does not claim those controls are implemented.

Use a staged evaluation: begin with a disposable environment and synthetic data; identify the actions available to agents; test invalid and adversarial inputs; observe logs and network requests; verify that cancellation works as expected; and ask a qualified security reviewer to assess the intended deployment. See the README and Agent Guide for project-specific caveats and currently implemented boundaries.

A helpful security review follows the code path for sensitive operations. For each operation, ask which process receives the request, what identity the process trusts, which data is read or changed, whether the action can contact another system, and how a person finds the audit evidence. Verify assumptions in code and configuration rather than relying on product descriptions alone.

Who HELLO OS is for

It may be a poor fit if you need a fully managed hosted product, verified native mobile packages, a mature enterprise permission model, a certified runtime, or guaranteed protocol interoperability today. The repository can still be useful for learning, prototyping, and identifying which controls a future system needs.

For a student or early-stage developer, the value may be in the concrete questions the code raises: How do I identify a running agent? How do I keep useful context without retaining everything? How do I expose capabilities through a named interface? How can a user pause or cancel a task? For a more experienced engineer, the value may be a compact reference project to inspect before deciding whether its architecture fits a new application.

How HELLO OS differs from a chatbot or agent framework

A chatbot interface primarily presents messages and responses. An agent framework commonly helps a developer build an agent loop, connect tools, and choose model behavior in code. An agent workspace adds application surfaces around that loop: records for identity and memory, task state, a human-facing dashboard, and a service interface that other clients can call.

HELLO OS is a prototype of that workspace idea. It does not replace a model provider, a general-purpose automation platform, or every framework. A team may use another agent library with a workspace, or treat the repository as a reference implementation while building a different system. The useful comparison is the set of operational needs: where the state lives, how tools are bounded, how a person inspects work, and what happens when a task needs to stop.

When evaluating alternatives, compare the actual supported behavior rather than labels. Check whether software is self-hosted, which protocols and versions it implements, how credentials are held, which models or tools are configured, what persistence is used, whether native releases exist, and how updates are delivered. For HELLO OS, the README, source tree, and setup guides are the primary evidence for those answers.

Some projects focus on model orchestration, others on tool calling, durable workflows, identity, or end-user chat. A workspace has to connect several of these interests while remaining understandable to its operator. This prototype gives developers a starting point for that exploration; it is not a universal comparison winner and does not make claims about competitors.

Static AML parsing and validation

The repository includes an AML compiler endpoint and MCP tool intended for static analysis of AML text. A developer can submit source to be parsed and receive validation findings without treating the endpoint as a live execution environment. This is useful when prototyping a language workflow or checking that a text input meets the validator’s supported grammar.

Static validation has a limited job: it can flag conditions represented by its parser and rules. It cannot prove the safety or business correctness of a program, check every external dependency, guarantee that a future runtime will behave the same way, or execute and authorize a transaction. Read a finding in context, review the source, and use additional tests appropriate to your application before relying on output.

For exact request shape and tool usage, consult the Agent Guide and current source. The API may evolve as the prototype changes. Treat its response as a developer aid and do not connect it to a production workflow that moves money, changes access, or performs another consequential operation without an independent review.

Inspect agent learning records

The HELLO OS Evolution Lab at http://localhost:3000/evolution creates persistent, seeded optimization runs and inspects saved candidate vectors, synthetic proxy fitness, mutation counts, and generation history. It also loads agent and mission counts, apprenticeship records, and curriculum data from app APIs. The optimizer does not train models, alter live agents, or spawn microVMs.

Read the Evolution Lab guide for schema setup, API routes, parameter bounds, and fitness limits. Scores are deterministic proxies over synthetic gene vectors, not evidence of agent learning or capability gains.

Open the HELLO EVOLVE browser simulation for an interactive, clearly labeled demo. Its agents, matches, scores, memory, and VM-style metrics are synthetic browser data.

Explore AML Studio

The HELLO OS app includes an interactive AML Studio route for static parsing and validation. Run the application locally, then open http://localhost:3000/aml-studio to inspect parsed declarations, diagnostics, intent graph nodes, and content hashes. The compiler does not execute AML or create digital signatures.

Read the AML Studio guide for endpoint examples and implementation boundaries, or visit the live-data Ecosystem dashboard source for the existing mission-control view.

Developer guide and open-source contribution

The repository is the source of truth for code, issues, and current implementation details. Start with the detailed README for the project overview and developer notes. Use the setup guide to start a local copy, the Agent Guide to see the agent-facing API surface, and the downloads guide for platform availability.

Before building an integration, verify endpoint paths, required environment variables, authentication assumptions, request schemas, error responses, and persistence behavior against the current branch. Prototype APIs can change. Pin a release or commit for experiments that must be repeatable, and include the commit hash when reporting a bug.

Contributors can help by clarifying setup instructions, adding reproducible tests, documenting API changes, improving error messages, and reporting security-relevant behavior through the project’s designated process. A useful issue includes the expected behavior, observed behavior, operating system, runtime versions, exact safe-to-share command output, and the smallest reproduction that demonstrates the problem.

Do not publish secrets, private keys, access tokens, personal data, or sensitive logs in public issues. Remove them before sharing diagnostic output. Review the repository’s contribution and security guidance before submitting a report.

Documentation changes are especially useful when they answer a question a new user would otherwise need to infer: where a service listens, what a command changes, which environment variables are required, and which functions are experimental. Keep a page aligned with visible code and remove claims when an implementation changes. Clear limitations help contributors make informed decisions and help users file more precise issues.

HELLO OS in search and AI answers

This page describes the project in plain text so a person, search crawler, or answer engine can understand the central entity and its limitations: HELLO OS is an open-source, local-first agentic OS prototype; it provides a human dashboard and explores identity, memory, MCP-compatible tools, and A2A-style task methods; Docker Compose is the documented quick start; native mobile and desktop installers are not published.

The page uses a descriptive title, a concise meta description, a canonical URL, crawlable links, semantic headings, visible project facts, and JSON-LD that reflects information shown on the page. The repository also publishes a sitemap and machine-readable project summaries. These are clarity and discovery aids. They do not force a crawler to visit, index, cite, or rank a page, and they do not guarantee inclusion in generative AI answers.

We do not use a meta keywords tag or repeated keyword blocks. Search phrases such as “open-source agentic OS,” “self-hosted AI agent workspace,” “local-first agent runtime,” “MCP-compatible agent tools,” “agent memory prototype,” and “A2A-style agent task API” appear only where they accurately describe the project. The page is written to answer relevant questions for developers, not to create separate thin pages for every wording variation.

Search performance can be measured only with access to the relevant search platform’s reporting tools and a defined date range. This project page does not claim a 100/100 SEO score, a specific organic position, a trending status, or that all crawlers have indexed it. Owners can verify indexing and queries through the respective webmaster consoles after adding and verifying the site.

Answer engines and search systems work best when the page states its subject plainly, uses useful headings, links to source documentation, and keeps facts consistent across the page and structured data. HELLO OS follows those practical principles while keeping the supporting evidence close: setup details link to setup docs, API details link to the Agent Guide, and repository claims link to the source. A crawler may choose any presentation or citation behavior; clear documentation cannot compel a particular answer engine to display this page.

Frequently asked questions about HELLO OS

Project links and technical references

• HELLO OS source repository — code, issues, and current project history.
• Project README — overview, architecture, setup notes, and boundaries.
• Getting started — local Docker and development setup.
• Downloads and platform status — what can currently be installed.
• Agent Guide — identity, memory, MCP, task methods, AML validation, and security boundaries.
• AML Studio guide — run and use the static AML validator locally.
• Evolution Lab guide — run persistent proxy-optimization experiments and inspect agent learning records.
• Machine-readable project summary — concise links and factual description for language-model tooling.
• XML sitemap — the public project documentation URLs.

HELLO OS is a public open-source project maintained in the linked repository. Read the repository’s license and project documentation for reuse terms and contribution details. For implementation questions, include a link to the relevant code or issue rather than relying on a search snippet.