janlucasandmann on Hacker News
Hey HN, Chatbots are amazing at conversation. They suck at getting shit done while you’re sleeping, in a meeting, or at the beach. So I built Computer Agents: real AI coworkers that each get their own isolated computer in the cloud. What actually happens when you create one:It boots its own persistent workspace (files, code, memory, everything survives forever) You give it a goal +...
Hey HN, Most AI “agents” I’ve tried are basically chatbots with amnesia — they forget everything the moment you close the tab and can’t do anything unless you’re sitting there watching them. I wanted real AI coworkers that just… work. So I built Computer Agents (aiOS). Every agent you create gets its own isolated computer in the cloud — complete with persistent memory, a real file system, code...
The core idea is simple: each agent gets its own isolated cloud computer with a persistent workspace. So instead of “chat request in, text out,” it’s “run real tasks, keep files/tools/state, continue later.”
What it does right now: Start or resume long-lived agent threads via API Run in isolated containers per environment Persist files/state between runs (workspace survives sessions) Stream execution events in real time (tool calls, logs, progress) Trigger runs from schedules and webhooks Access from web/iOS/Telegram + API/SDKs (TS + Python)
Why I built it: Local agent workflows are powerful, but tied to one machine/session Stateless LLM APIs are easy to call, but hard to turn into reliable “ongoing workers” I wanted something that behaves more like a junior teammate with a desk/computer, not just a chat box Things that were surprisingly hard:
Keeping runtime behavior aligned with docs/instructions over time Avoiding ephemeral /tmp output issues and ensuring artifacts land in persistent workspace paths Container warm/reuse logic without breaking thread continuity Cost/usage visibility per run If this sounds useful, I’d love feedback on:
API shape for thread/run lifecycle What “production-ready” means for agent infrastructure Which integrations you’d want first (GitHub, Slack, etc.) If useful, I can share the exact API flow and architecture decisions in a follow-up comment.
We've been building Computer Agents for the past year, and today we're sharing it publicly.
The problem we kept hitting: AI can reason impressively, but getting it to do anything meaningful requires duct-taping together a dozen tools. You prompt, copy the output, paste it somewhere, run it manually, fix the errors, repeat. The bottleneck isn't intelligence anymore: it's execution.
What we built: An operating system where AI agents can actually operate. They get isolated environments with a real filesystem, terminal, browser, and the ability to execute code. You give them a task, they figure out how to do it, and they do it.
How it works: - Each agent runs in an isolated container with its own workspace - Agents can read/write files, run shell commands, browse the web, and call APIs - You can run tasks from our web app, API, or messaging apps (Telegram, Discord) - Results come back with the actual artifacts: files created, code written, data extracted
Example tasks our users run: - "Fix the TypeScript errors in this repo" → agent clones, fixes, tests, commits - "Research competitors and create a summary doc" → agent browses, extracts, writes - "Process this CSV and generate a report" → agent analyzes, visualizes, exports - "Review this PR for security issues" → agent reads diff, analyzes, comments
Tech stack (for the curious): - Agents run on GCE with Firecracker-style isolation - Workspaces sync to GCS for persistence - We use Claude and GPT-4 for the reasoning layer - MCP (Model Context Protocol) for tool integrations - Next.js frontend, Firebase auth, Firestore for state
What surprised us: The Telegram integration became unexpectedly popular. People run agents from their phone while commuting. "Fix the prod bug" from a train is apparently a thing now.
What we're still figuring out: - Long-running tasks (hours) and how to handle interruption gracefully - Cost predictability: agents can go deep, which burns tokens - The right abstraction for multi-agent workflows
Pricing: Free tier with limited compute, then usage-based. We're not trying to get rich on margins — the goal is making this accessible.
We'd love feedback from HN, especially: - What would you actually use this for? - What's missing that would make you switch from your current workflow? - Anyone else building in this space we should talk to?
Site: https://computer-agents.com Docs: https://computer-agents.com/documentation
Happy to answer questions about the architecture, our agent design, or anything else.