# Alook: a collaboration layer that gives local coding agents an identity and an inbox

> Alook connects the coding agents already running on your machine to shared rooms where people can talk with them. It is a coordination layer, not a model host, and its README is clearer about the idea than about operations.

**alookai/alook** — Project brief: The collaboration layer for your AI workforce. Run a team of AI agents that coordinate over email, share memory, and get better with every task.

- Repository: https://github.com/alookai/alook
- Website: https://alook.ai
- Stars: 1,191 · Forks: 189
- Language: TypeScript
- License: Apache-2.0
- Published: 2026-08-08 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/alookai-alook

## The gap Alook targets: agents you cannot address

A coding agent running in a terminal is reachable by exactly one person, on one machine, through one session. If a colleague wants that agent to do something, they either walk over or they ask you to ask it. Alook's answer is to give the local agent a persistent identity: a handle, an inbox, and memberships in rooms, so that teammates can address it in servers, channels and DMs the same way they address a person. The README frames this as "where people and AI agents share the same rooms." The intended user is a team that already has agents on individual laptops and wants them to be shared resources without moving the runtime to a hosted environment. That is a narrower audience than a general chat product, and the README is honest about the boundary: Alook does not supply or host its own models, it gives an existing agent a way to be reached.

## How the daemon, the workers and the agent workdir fit together

The contributing section carries a Mermaid diagram that lays out three zones. On the agent machine there is a CLI package, @alook/daemon, and an agent workdir. On the hosted side there is @alook/app plus queues. Storage is split between SQLite and files. The arrow between the two machines is labelled WebS, which is a truncation of WebSocket in the README text. The package.json fills in the rest of the shape: the dev script runs turbo across @alook/web, @alook/email-worker, @alook/ws-do, @alook/queue-worker and @alook/shared. The ws-do package is the WebSocket Durable Object, and .env.example notes its URL must match the port in src/ws-do/wrangler.toml, defaulting to http://localhost:8789. The email worker runs on 8787. The daemon exposes a health check server whose port defaults to 19514. So the data flow reads as: your agent keeps running locally, the daemon holds the connection outward, the Durable Object coordinates live presence, and the email worker handles the inbox side of the identity. The README does not document what the daemon writes into .alook/, and it does not describe reconnection behaviour when the WebSocket drops.

## Installing Alook and getting a first agent into a room

The README gives a single quick-start command. It walks through connecting the machine, detecting runtimes, and starting Alook locally; the documentation states that you open http://localhost:15210 when it finishes.

```bash
npx @alook/app onboard
```

If you would rather not run the CLI, the README offers a second path: go to alook.ai and connect a local runtime from there. The supported runtimes are listed in a table: Claude Code, Codex, Cursor, OpenCode and Pi. Alook connects to the coding agents already on your machine, so the practical first step is to have one of those installed and working before you onboard. For contributors working from source, the root package.json defines the workspace scripts. A predev hook copies src/web/.dev.vars.example to src/web/.dev.vars and generates BETTER_AUTH_SECRET and ENCRYPTION_KEY with openssl rand -base64 32, then syncs ENCRYPTION_KEY into the email-worker and queue-worker .dev.vars files.

```bash
pnpm dev
```

The dev script filters turbo to @alook/web, @alook/email-worker, @alook/ws-do, @alook/queue-worker and @alook/shared. The .env.example states that all variables are optional and that sensible defaults are built in, and that dev:cli sets ALOOK_SERVER_URL and ALOOK_PROJECT_ROOT automatically, so .env overrides are only needed for non-default agent paths or daemon tuning. Note the macOS-specific sed -i '' syntax in the predev hook; on Linux that form fails.

## Where the documentation stops short

The README is a product page, not an operations manual. Several things a team would need before rolling this out are simply absent. There is no documented rollback path, no description of what happens to queued messages when the daemon is offline, and no retention or deletion policy for the SQLite and file storage the diagram shows. The README also does not explain how room membership is enforced, which matters because the whole premise is inviting people you trust into a room with an agent that has access to your machine. The runtime support table lists five agents with a status column showing Supported for each, but gives no version floors, so it is unclear which Claude Code or Codex builds the daemon has been exercised against. The project is not archived and the last push was on 2026-08-28, with v0.1.24 tagged the same day, so the code is moving. That also means interfaces can shift under you; the 0.1.x version line and three releases inside two days suggest the shape is still settling. If you need a stable integration surface today, this is early.

## When a shared agent room is the wrong tool

Alook solves reach, not capability. If your problem is that one developer wants a better coding assistant in their own terminal, adding a daemon, a WebSocket Durable Object and an email worker to the loop buys you nothing and costs you a running service. If you need an agent that works while your laptop is closed, Alook is the wrong shape by design: the README states the agent stays on your machine, so the machine has to be on. If you want a hosted model, the README is explicit that Alook does not supply or host its own models, so there is nothing to sign up for on that front. And if your team cannot agree on who may join a room with an agent that has filesystem access through its workdir, the collaboration feature is a liability rather than a feature. The README does not document per-room permissions, so that question has to be answered from the source before you invite anyone.

## How this differs from running an agent behind a chat bridge

The common alternative is a chat bridge: you wire an existing agent into a messaging platform with a bot token and a webhook, and people talk to it in that platform's channels. That approach reuses infrastructure you already run and inherits its permissions model. The difference in Alook is the identity layer. A bridge typically gives you one bot account for the whole workspace; Alook gives each agent a handle, an inbox and memberships, so an agent is addressable as an individual across every room it belongs to. The email worker in the workspace is what makes the inbox part real rather than cosmetic. The trade-off is that you are now running Alook's own stack, including the Durable Object and queue worker, instead of leaning on a platform you already operate. A bridge also usually assumes the agent is reachable from the cloud; Alook assumes the opposite, which is the whole point of the local-first framing but also the source of the always-on requirement.

## Licence and the cost of staying current

Alook is Apache-2.0, which permits commercial use and modification and includes an explicit patent grant. The practical implication for a team embedding it: you can fork and ship, but you inherit the obligation to carry the licence and attribution, and the repository's NOTICE-style files (LICENSE, and the project metadata) should travel with any redistribution. That is a description of the licence text, not legal advice; get a lawyer for anything binding. On upgrade cost, the release cadence is the signal. Three tags landed between 2026-08-27 and 2026-08-28, and the last push was on 2026-08-28. The workspace is a pnpm monorepo with turbo, so upgrading means keeping the daemon, the web app and the workers in step; the predev hook that syncs ENCRYPTION_KEY across three .dev.vars files is a small hint that these components are coupled through shared secrets. Plan on reading release notes per bump rather than floating a range. The README does not describe a migration process between versions.

## Conclusion

Alook fits teams that already run Claude Code, Codex, Cursor, OpenCode or Pi locally and want those agents reachable in shared rooms without moving them off the machine. It does not fit anyone looking for a hosted model or a single-user coding assistant, since the project states it supplies no models of its own. Before adopting it, read src/daemon and src/ws-do, confirm which daemon version your runtime needs, and check what the daemon writes into .alook/ and how you would remove it.

## FAQ

### What is the Alook app?

Alook is a collaboration layer for AI agents. It gives the coding agents already running on your machine a handle, an inbox and room memberships so that people you trust can address them in servers, channels and DMs.

### Which coding agents does Alook support?

The README's runtime table lists Claude Code, Codex, Cursor, OpenCode and Pi, each marked Supported. It does not give version floors for any of them.

### Does Alook host its own models?

No. The README states that Alook connects to the coding agents already on your machine and does not supply or host its own models; it gives the agent a way to be reached.

### What port does Alook run on locally?

The quick start says to open http://localhost:15210 after onboarding. The contributor services use their own ports: the WebSocket Durable Object defaults to 8789 and the email worker to 8787.

## Sources

- [Official documentation](https://alook.ai)
- [Official README](https://github.com/alookai/alook#readme)
- [Project repository](https://github.com/alookai/alook)
- [Release notes](https://github.com/alookai/alook/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/alookai-alook