Architecture

nebflow organizes AI work around a single entry point and a small set of concepts: Nebula, the orchestrator you talk to; a task, which is the only way project work begins; a per-project task dispatcher that splits work into a graph of nodes; nodes that all run the same general base agent, shaped per node by plugins; and a supervision tree that keeps long-running work healthy. This page is the panoramic view — every section links to a dedicated page.

One entry point: Nebula

• You talk to Nebula in plain language: it understands what you want, coordinates the work, and reports back — the single conversational entry to everything nebflow does
• Nebula itself stays deliberately lean: three read-only tools for inspecting your workspace (Read / Glob / Grep) plus one structured write, MemoryEdit. No shell, no file editing — execution is delegated to projects, not done inline
• Between sessions, what Nebula knows persists as memory, updated only through MemoryEdit

Tasks start projects

• A task is the only way project work is triggered: describe the outcome you want, and the task becomes a project
• There is no separate automation layer to wire up — one sentence is enough to start, and everything that follows stays visible on the project's task graph

Every project gets a task dispatcher

• Each project has its own task dispatcher: it splits the task into nodes, wires the edges between them, and lets results flow back along those edges
• The graph is the plan of record: follow progress and rewire it on the Flow Map while work runs, and adjust any node in place with NodeEdit — finished results are kept, so re-planning never forces a re-run
• Capabilities are assigned per node — individual plugins or a saved preset — picked at dispatch time
• Nodes are deliberately lightweight: no memory, no identity of their own. Everything that matters lives in the graph, so a project stays easy to reason about at any size

See Task Dispatcher.

Nodes are uniformly general

• Every node runs the same general base agent — there is no zoo of agent types to create and maintain
• What a node knows how to do comes from its assigned plugins: injected skills and the resources they reference. The tool face is not a plugin's business — the engine fixes it by role. See Specialized Agents
• Every node executes inside the sandbox: file writes stay in the project workspace and sensitive paths are off limits, no matter what the node runs

Capabilities ship as plugins: Agent Plugins 1.0.0

• Every capability an agent can have — a methodology skill, a domain reference, a review discipline — ships as a plugin: a plain folder with a manifest following the open Agent Plugins 1.0.0 format
• Plugins reach a node only once you install them: a plugin you have not installed simply is not there, and installing one records a digest of the entire content

See Plugins.

The supervision tree

• Long-running work is supervised, not fire-and-forget. A watcher keeps an eye on running work; the dispatcher performs first-line self-healing — a failed node is re-dispatched without redoing the rest of the graph; and Nebula is the backstop when a project needs intervention from the top
• Failures stay contained and visible: a failed node settles as failed on the Flow Map, completed results stay put, and you always see which part of the graph needs attention

Where to go next

• Curious how a single session carries a task end to end? See Sessions.
• Want the mechanics of splitting up work? Read Task Dispatcher.
• Ready to extend what agents can do? Start with Plugins.