AI agent orchestration platform. Workspaces run autonomous agents triggered by signals (HTTP, cron).

The daemon manages workspace lifecycles — each workspace defines agents, signals, and jobs in a workspace.yml. Signals arrive (HTTP, CLI, cron), the daemon routes them to the workspace runtime, which spawns sessions where agents execute with MCP tool access.

Quickstart

Prerequisites

You do not need Postgres for local development — the daemon uses SQLite by default. Postgres is only required when running the link credential service in production.

1. Clone and install

git clone https://github.com/friday-platform/friday-studio
cd friday-studio
deno install                    # install JS/TS deps (also runs husky via prepare hook)

2. Configure environment

cp .env.example .env
# open .env and set ANTHROPIC_API_KEY (or another provider key)

The example file documents every variable the daemon reads. The minimum to run a real agent is one LLM provider key.

3. Start the daemon

deno task atlas daemon start --detached

Verify it's up:

curl -sf http://localhost:8080/health && echo "  daemon ok"
deno task atlas daemon status

4. Run your first agent

Send a prompt through the CLI — the daemon routes it to the bundled chat workspace and returns a chat id you can follow up on.

deno task atlas prompt "Write a haiku about TypeScript"
deno task atlas chat                    # list recent chats
deno task atlas chat <chatId> --human   # readable transcript

To run one of the bundled example workspaces (HTTP-triggered Claude Code agent):

deno task atlas workspace add ./examples/claude-code-smoke
curl -X POST http://localhost:8080/webhooks/run-code \
  -H "Content-Type: application/json" \
  -d '{"prompt": "explain this repo in two sentences"}'

Browse examples/ for more — pr-review-github, jira-bugfix-labeled, claude-code-with-skills, and others — each is a self-contained workspace.yml you can copy and edit.

5. Stop the daemon

deno task atlas daemon stop

Alternative: Docker

docker compose up

This runs the daemon, web UI (Studio), credential service, PTY server, and webhook tunnel together. Ports default to 1xxxx to avoid host collisions — see docker-compose.yml.

Web playground (optional)

For interactive development with the Svelte UI, hot-reload daemon, and webhook tunnel running side by side:

deno task dev:playground

Open http://localhost:5200.

Local development

Working in-tree (running the daemon out of the repo, not via the desktop installer) needs a one-time setup so the daemon's user-agent spawn path finds a managed Python with the SDK installed:

bash scripts/setup-dev-env.sh

Idempotent. Safe to re-run after every friday-agent-sdk version bump.

What it does:

1. Verifies uv is on PATH (installs from astral.sh if not).
2. Writes the env vars the daemon needs (FRIDAY_UV_PATH, UV_PYTHON_INSTALL_DIR, UV_CACHE_DIR, FRIDAY_AGENT_SDK_VERSION) into the daemon's envfile (~/.atlas/.env or ~/.friday/local/.env, matching whichever home holds your live state).
3. Pre-warms the uv cache — Python 3.12 + the pinned friday-agent-sdk wheel — so the first user-agent spawn doesn't pay the download as cold-start latency.
4. Uninstalls any stale editable friday-agent-sdk installs from system Pythons that would otherwise shadow the uv-managed copy.

Restart your daemon after running it so the new env vars take effect.

The desktop installer handles the same setup automatically; this script is for in-tree development only.

Commands

# Daemon lifecycle
deno task atlas daemon start --detached   # start (background)
deno task atlas:dev daemon start          # start with auto-restart (session-aware)
deno task atlas daemon status             # health check
deno task atlas daemon stop               # stop

# Interact
deno task atlas prompt "your prompt"      # send a one-shot prompt
deno task atlas chat                      # list recent chats
deno task atlas chat <chatId> --human     # show transcript

# Develop
deno task typecheck                       # deno check + svelte-check
deno task lint                            # deno lint + biome check --write
deno task fmt                             # biome format --write
deno task test $file                      # run a vitest file

# Go services
go test -race ./...
golangci-lint run

Project Structure

apps/
  atlasd/             # Daemon — HTTP API, workspace lifecycle (TS/Deno)
  atlas-cli/          # CLI entry point — `deno task atlas` (TS/Deno)
  link/               # Credential / OAuth service (TS/Deno)
  ledger/             # Resource & activity storage service (TS/Deno)
  studio-installer/   # Friday Studio launcher app — tray, daemon
                      # supervisor, autostart (Tauri/Rust)
packages/             # @atlas/* libraries — core, agent-sdk, config,
                      # fsm-engine, llm, logger, mcp, memory, skills,
                      # storage, workspace, signals, …
examples/             # Self-contained workspace.yml examples
                      # (claude-code-smoke, pr-review-github,
                      # jira-bugfix-labeled, …)
tools/
  agent-playground/   # Web client (SvelteKit) — dev tool and the
                      # production UI bundled in Friday Studio
  evals/              # Agent eval harness CLI
  friday-launcher/    # System tray launcher + daemon supervisor (Go)
  pty-server/         # WebSocket → PTY shell bridge (Go)
  webhook-tunnel/     # Cloudflare tunnel → daemon webhook forwarder (Go)

Config: friday.yml (platform-wide) · workspace.yml (per-workspace) · CONTRIBUTING.md (dev guidelines + code style)

Python user agents

A workspace agent declared type: "user" is a Python file the daemon spawns as a subprocess. The agent code calls capabilities (LLM, HTTP, MCP tools, streaming) over NATS through the friday-agent-sdk package — no provider keys, no MCP plumbing in your code.

Minimal agent:

from friday_agent_sdk import AgentContext, agent, ok

@agent(id="hello", version="1.0.0", description="Reverses input.")
def execute(prompt: str, ctx: AgentContext):
    return ok({"reversed": prompt[::-1]})

if __name__ == "__main__":
    from friday_agent_sdk import run
    run()

Register and run:

curl -X POST http://localhost:8080/api/agents/register \
  -H "Content-Type: application/json" \
  -d '{"entrypoint":"/abs/path/to/agent.py"}'

curl -X POST "http://localhost:8080/api/agents/hello/run?workspaceId=user" \
  -H "Content-Type: application/json" \
  -d '{"input":"hello"}'

The daemon spawns uv run --python 3.12 --with friday-agent-sdk==<pinned> agent.py under the hood — the version is pinned in tools/friday-launcher/paths.go (bundledAgentSDKVersion) and threaded through to the daemon via the launcher (or setup-dev-env.sh for in-tree work). Bumping the SDK is a deliberate change in three pin sites: that constant, the same value in the Dockerfile, and BUNDLED_AGENT_SDK_VERSION in apps/studio-installer/src-tauri/src/commands/prewarm_agent_sdk.rs.

Rule of thumb: use type: "user" only when each call's decision is mechanical (regex / schema / fixed routing). For any LLM-judgment work (classifying, summarizing, choosing among options), use type: "llm" with MCP tools — that's faster to author and easier to maintain.

Reference:

• SDK: friday-platform/agent-sdk · authoring guide vendored at packages/system/skills/writing-friday-python-agents
• Memory access from agents: narrative is the only supported strategy today — see packages/system/skills/writing-to-memory
• Spawn resolution: apps/atlasd/src/agent-spawn.ts — three-tier fallback (uv-run → FRIDAY_AGENT_PYTHON → bare python3)

AI Workflow

Claude Code skills support a structured planning-to-execution pipeline:

1. Design — /brainstorming refines a rough idea into a design doc via Socratic questioning. Outputs to docs/plans/.

2. Iterate — /improving-plans critiques the design, surfaces gaps, and outputs an improved version. Keep iterating until the questions become trivial.

3. Tasks — /creating-tasks converts the validated design into tracked work items with dependency graphs.

4. Execute — /implementing-tasks spawns parallel agents. Each claims a task, implements, commits, moves on.

5. Polish — /polishing runs a self-review team (lint, slop, tests, design) before PR.

6. Ship — /opening-pr creates a PR with summary and test plan.

Post-ship: /reviewing-code for reviewing others' PRs.

Learn more

• docs/ARCHITECTURE.md — components and data flow
• CONTRIBUTING.md — how to send patches, code style, hard rules (CLA required)
• SECURITY.md — vulnerability disclosure

License

Friday is source-available under the Business Source License 1.1. You can read, modify, and self-host the code under the Additional Use Grant, which permits free production use for personal use, organizations under 5 people, and businesses with under $1M ARR. Production use outside those bounds, or that competes with Tempest Labs' offering, requires a commercial license. Each released version converts automatically to Apache-2.0 one year after that version is first distributed (so the current version's Change Date is 2027-04-30; later versions get their own date).

For commercial-license inquiries: legal@tempest.team.

Third-party components retain their original licenses — see THIRD_PARTY_LICENSES.md and NOTICE (includes MPL-2.0 §3.2 source-availability notice and license elections for dual/tri-licensed deps).