Skip to content

tinoosan/agen8

Repository files navigation

Agen8

A context system for AI teams.

image

AI agents are powerful, but the surrounding workflow is still broken. Plans live in markdown, decisions live in chat, tasks live somewhere else, and rationale disappears between sessions. Teams end up reconstructing state from transcripts, tool logs, and memory.

Agen8 turns agent work into structured context that can be carried forward, inspected, and acted on. Prompts, plans, decisions, tasks, and execution traces become one shared operational surface for humans and agents.

Alpha. Agen8 is under active development. Rough edges remain. If you're here, you're early.

The Problem

Most agent workflows eventually collapse into fragmented context:

  • execution happened, but intent is hard to recover
  • decisions were made, but rationale is buried in transcripts
  • plans exist, but drift is hard to explain
  • handoffs happened, but continuity is weak across sessions and models

This is why teams lose trust and spend time on transcript archaeology instead of steering outcomes.

Core Differentiation

Agen8 does not just run agents. It preserves and structures their work over time.

Most tools generate outputs. Agen8 builds context.

What Agen8 Is

Agen8 is a shared context layer for AI-native teams. It treats operational artifacts as first-class system state, not chat fragments:

  • missions and key results define intent
  • plans are durable, editable objects
  • tasks and reviews capture execution and quality gates
  • decisions, escalations, and operator actions preserve rationale
  • strategy map links everything into a live context graph

Instead of coordinating through chat history and memory, you coordinate through a living system of record that both humans and agents can use. Instead of rebuilding context every time, you work on top of it.

Product Model

Agen8 is designed as four connected layers:

  • Execution: agents perform work
  • Coordination: teams, roles, routing, and review loops
  • Context: missions, key results, plans, decisions, and links
  • Surfaces: chat, board, files, inspector, and strategy map

Positioning

Agen8 is for people already serious about agentic work and now blocked by trust, continuity, and coordination overhead:

  • technical founders and solo builders running heavy agent workflows
  • AI-native product and engineering operators
  • small teams already using tools like Codex, Claude Code, and Cursor-style workflows that need stronger visibility and steering loops

Why Agen8

Agen8 is not another wrapper around a single agent runtime. It is built for AI-native work where teams are partly human and partly model-driven.

Most agent tools optimize execution. Agen8 optimizes continuity.

Three design principles drive the product:

  • Run AI teams, not isolated agents
  • Observe work through multiple surfaces (tasks, board, strategy map, threads, trace), not one transcript
  • Preserve why work happened, not just the latest answer, so context survives across sessions and models

The system uses the same primitives humans already use to coordinate, but makes them programmable and agent-native:

  • Projects scope the work
  • Missions and key results define what success looks like — agents track progress against them as they work
  • Teams define who does what
  • Roles give each agent a specialty, tools, and boundaries
  • Tasks flow down with goals and acceptance criteria, results flow back up through review
  • Messages follow hub-and-spoke — coordinators talk, workers execute
  • Escalations and operator actions surface decisions that need a human
  • Schedules keep agents proactive (heartbeats, cron, one-off wake-ups)
  • Reviews gate quality before work is accepted
  • Notifications push when something needs attention

These are not "AI abstractions." They are operational abstractions. Missions, key results, plans, tasks, decisions, escalations, and requests are first-class system objects, not chat fragments. Each project becomes a durable context system where teams run, make decisions, and leave an inspectable history that both humans and agents can query and build on.

What you get

A strategy map that shows the full picture

The strategy map is a spatial knowledge graph of everything happening in a project — missions, key results, tasks, decisions, operator actions, and escalations — laid out as a navigable graph. Click any node to see its local neighbourhood: what feeds into it, what it drives, what's blocked. The map updates live as agents work.

It is not just a visualization layer. It is a queryable context graph for work and a shared memory layer for AI teams. Humans inspect and steer, while agents traverse and reuse structure during execution. It is the fastest way to go from "what's the status?" to a specific task or decision without touching a single conversation thread.

image

A board and task detail scoped to the work

The kanban board tracks every task coordinators create — queued, blocked, working, in review, done, failed. Open any task to see its detail — the goal, who it's assigned to, what came back, what it cost. The context is scoped to the work, not scattered across a conversation thread. (Task activity timeline in progress.)

image image

Conversations you can follow

When you talk to the coordinator, you see the conversation as a thread — your messages, the coordinator's reasoning, task delegations, results coming back from workers. When it delegates, you see what it asked for. When work comes back for review, you see the handoff. It reads like a paper trail, not a chatlog.

Teams that talk to each other

Coordinators can message other coordinators across teams — inform, query, broadcast. A CEO coordinator with no workers of its own can orchestrate an entire company of teams through messages alone. An engineering CTO can ask the product team for requirements and get a response threaded back. You can watch these conversations unfold in real time in the web UI, grouped by team pair, with task assignments, broadcasts, and responses all visible in one stream.

Flexible team shapes

Teams come in two shapes:

  • A lone coordinator — handles work directly through conversation and tools, and can orchestrate other teams via messages. A CEO coordinator with no workers of its own can run an entire company by delegating across engineering, product, design, finance, and growth teams. On its own, it's effectively a capable solo agent.
  • A coordinator with specialists — a CTO with backend, frontend, devops, and QA engineers. A managing partner with strategy analysts, researchers, and writers. The coordinator breaks down work, delegates to the right roles, reviews what comes back, and keeps going.

19 team templates ship as defaults — from a general-purpose coordinator to a consulting firm with six roles to an artist management team with parallel workstreams. Customize them or build your own in the web UI.

Multi-team projects

Projects can run multiple teams at once. Build your teams and roles in the web UI — no config files required. Multiple teams share a project, each with their own coordinator, and the executive layer ties it together through inter-team messaging. The runtime starts teams, recovers stalled ones, and keeps work moving.

Planning and memory

Every run has a virtual filesystem. /plan holds the active plan — a checklist and details doc backed by SQLite, visible per-role in the web UI with progress bars and step indicators. /memory holds shared memory as daily files — categorized entries (decisions, corrections, patterns, blockers) that agents write to and search across. Heartbeat jobs can consolidate memory on a schedule.

Tools and skills

Agents get filesystem operations, Python execution with a tools bridge, shell access, HTTP requests, a Playwright browser with tabs and session state, inter-team messaging, task delegation, email notifications. Tool access is policy-controlled per role — a coordinator gets task_create and task_review, a code worker gets shell_exec, a web researcher gets browser.

Skills are SKILL.md files that live in ~/.agents/skills/. Some default skills are seeded on first run, including the official gws-shared Google Workspace CLI skill. If you want agents to work through gws, install @googleworkspace/cli, store auth with agen8 creds set gws --kind shell ..., and grant the role both gws-shared and shell_exec. Roles declare which skills they can see in team.yaml.

How it works

Build teams in the UI — or define them as code

The web UI has a team and role builder — pick a template, configure roles, set tools and models, and start the team. No files required.

For teams you want to version-control or deploy from code, teams are plain YAML and Markdown:

my-team/
  team.yaml          # roles, models, coordination rules
  roles/
    coordinator/
      role.yaml      # goals, allowed tools
      prompt.md      # who this agent is
    engineer/
      role.yaml
      prompt.md

Either way, the runtime behaviour is identical.

You talk to the coordinator

You don't write task specs or route work. You talk to the coordinator the way you'd talk to a tech lead — "here's what I need, figure it out." The coordinator decides what to delegate, creates tasks for the right roles, and when results come back, reviews them. It approves good work, retries with feedback when something's off, and escalates when it's stuck.

Work flows down the tree and results flow back up through review gates.

Heartbeats keep things moving

Roles can define heartbeat jobs — recurring tasks on a schedule. A software developer's heartbeat keeps the build green every 12 hours. A stock analyst refreshes its watchlist daily. A consulting firm's coordinator checks in on stalled work every 10 minutes. The runtime handles deduplication and backpressure so heartbeats don't pile up.

Get running

Prerequisites: Go 1.24+, a writable $AGEN8_DATA_DIR (defaults to ~/.agen8).

go build ./cmd/agen8
./agen8 daemon start
./agen8 project init
./agen8 web

For development: make dev gives you Go hot reload and the Vite web UI. Missing tools get bootstrapped automatically.

Commands

Command What it does
agen8 daemon start|status|stop Run the runtime
agen8 project init|status|apply|export|delete-teams Bind a project and manage its desired-state
agen8 creds set|list|show|remove Manage runtime credentials for builtin tools such as http and shell_exec
agen8 web Open the web UI (primary operator surface for teams, threads, and tasks)
agen8 logs --follow Watch the runtime

Configuration

CLI flags > env vars > config.toml > defaults.

Flag Env What it sets
--data-dir AGEN8_DATA_DIR Runtime state directory
--workdir AGEN8_WORKDIR Host path for /project
--auth-provider AGEN8_AUTH_PROVIDER api_key or chatgpt_account

Supports OpenRouter, OpenAI API keys, and ChatGPT browser OAuth. Full reference in docs/config-toml.md.

Docs

CLI usage Workflows and flags
Connectors guide Setting up managed connectors like Brave Search
Remote bridge creator guide Hosted-mode setup for agen8 connect
Configuration Config hierarchy and settings
Project manifest Project and team configuration
Team definitions team.yaml, roles, prompts
Auth ChatGPT OAuth setup
Architecture Internal design
Execution model Orchestration spec (draft)
Data layout Runtime directories
Troubleshooting Common issues

On building this

Agen8 is built with AI-assisted coding. The strict hierarchy, the review gates, the separation of messages from tasks — none of that came from a design doc. It came from watching agents fail without those constraints and fixing it.

One person and a lot of AI. If the architecture holds up, that's the point.

License

See LICENSE for details.

About

A context system for AI teams. Most tools generate outputs. Agen8 builds context.

Topics

Resources

License

Stars

Watchers

Forks

Releases

No releases published

Packages

 
 
 

Contributors