{"slug": "celorga-org-mode-as-agent-orchestration-infrastructure", "title": "Celorga: Org-Mode as Agent Orchestration Infrastructure", "summary": "The Celorga project rebuilt Emacs Org-mode as a standalone Node.js CLI and MCP server, exposing TODO items, agenda queries, and structured notes as callable tools for multi-agent workflows. The server acts as a stateless adapter that translates Model Context Protocol calls into plaintext .org file operations, letting agents and humans share a single filesystem-based source of truth, with a trigger_agent tool that reads an :AGENT: property to spawn processes or make HTTP calls.", "body_md": "Celorga strips Emacs Org-mode down to a standalone CLI and rebuilds it as agent infrastructure. The project exposes TODO items, agenda views, and structured notes as MCP server tools, turning 15 years of plaintext task management conventions into coordination primitives for multi-agent workflows.\n\nThe architecture is interesting because it decouples the data format (Org-mode's plaintext structure) from the editor (Emacs) and adds agent-facing APIs without breaking compatibility. You get a portable task manager that agents can read, write, and trigger actions from.\n\nCelorga reimplements Org-mode's core features as a Node.js CLI:\n\n`.org` files\nThe MCP server is the bridge. It wraps Org-mode operations (query agenda, update TODO state, add notes) as callable functions that any MCP-compatible agent can invoke. This means Claude Desktop, custom harnesses, or any tool speaking the Model Context Protocol can treat your task list as a structured API.\n\nThe stack looks like this:\n\n```\n┌─────────────────────────────────────┐\n│  Agent (Claude, custom harness)     │\n└─────────────┬───────────────────────┘\n              │ MCP protocol\n┌─────────────▼───────────────────────┐\n│  Celorga MCP Server                 │\n│  - agenda_query()                   │\n│  - update_todo()                    │\n│  - add_note()                       │\n│  - trigger_agent()                  │\n└─────────────┬───────────────────────┘\n              │ File I/O\n┌─────────────▼───────────────────────┐\n│  .org files (plaintext)             │\n│  * TODO Deploy staging              │\n│    SCHEDULED: <2026-10-20>          │\n│    :PROPERTIES:                     │\n│    :AGENT: deploy-bot               │\n│    :END:                            │\n└─────────────────────────────────────┘\n```\n\nState lives in plaintext `.org` files on disk. The MCP server parses these files, exposes structured operations, and writes changes back. Native apps and the CLI read the same files, so humans and agents share a single source of truth.\n\nThe \"kick off your agents easily from any TODO\" feature works through custom properties. You tag a TODO item with an `:AGENT:` property pointing to a script, API endpoint, or agent harness. When the MCP server's `trigger_agent()` tool is called, it reads the property and spawns the corresponding process or makes the HTTP call.\n\nCelorga avoids a central server by treating the filesystem as the coordination layer. All clients (CLI, native apps, MCP server) read and write the same `.org` files. Conflicts are handled at the file level using standard merge strategies.\n\nThis works because Org-mode's format is line-oriented and human-readable. Git or Syncthing can merge changes without understanding the semantics. The MCP server doesn't hold state; it's a stateless adapter that translates MCP calls into file operations.\n\nTrade-offs:\n\n| Approach | Conflict Handling | Latency | Complexity | \n|---|---|---|---|\n| Filesystem sync | Manual merge or last-write-wins | Local read/write speed | Low (no server) | \n| Central server | Operational transform or CRDT | Network round-trip | High (server ops, auth) | \n| Event log | Append-only, deterministic replay | Depends on log storage | Medium (replay logic) | \n\nCelorga picks filesystem sync because Org-mode users already expect to manage `.org` files in Git or Dropbox. The format's plaintext nature makes conflicts visible and resolvable.\n\nThe MCP server exposes Org-mode operations as tools. Here's what a typical tool definition looks like:\n\n```\n{\n  name: \"agenda_query\",\n  description: \"Query TODO items matching criteria\",\n  inputSchema: {\n    type: \"object\",\n    properties: {\n      tags: { type: \"array\", items: { type: \"string\" } },\n      state: { type: \"string\", enum: [\"TODO\", \"DONE\", \"WAITING\"] },\n      scheduled_before: { type: \"string\", format: \"date\" }\n    }\n  }\n}\n```\n\nWhen an agent calls `agenda_query`, the server:\n\nThe `trigger_agent` tool reads the `:AGENT:` property from a TODO item and executes it. If the property is a shell command, it spawns a subprocess. If it's a URL, it makes an HTTP POST with the TODO's context as JSON payload.\n\nThis design lets you wire up arbitrary automation without hardcoding agent types. A TODO item can trigger a GitHub Actions workflow, a local Python script, or another MCP server.\n\nCelorga adds several primitives beyond basic Org-mode:\n\n`:AGENT:` properties map TODOs to runnable code\nThese primitives turn a task list into a lightweight orchestration layer. You can model multi-step workflows as nested TODO trees, where each item triggers a different agent and the parent tracks overall progress.\n\nExample workflow:\n\n```\n* TODO Deploy new feature\n** TODO Run tests\n   :PROPERTIES:\n   :AGENT: pytest-runner\n   :END:\n** TODO Build container\n   :PROPERTIES:\n   :AGENT: docker-build\n   :END:\n** TODO Push to staging\n   :PROPERTIES:\n   :AGENT: kubectl-deploy\n   :END:\n```\n\nAn agent queries the agenda, sees the top-level TODO, and walks the subtree. It calls `trigger_agent` on each child in sequence, updating their state as they complete.\n\nCelorga's stateless design creates specific failure modes:\n\n`trigger_agent` call fails silently unless you add logging.\nObservability is minimal. The MCP server logs tool calls to stdout, but there's no built-in tracing or metrics. You'd need to wrap the server in a logging proxy or instrument the triggered agents themselves.\n\nFor production use, you'd want:\n\nCelorga makes sense when:\n\nAvoid it when:\n\nThe project is most useful as a bridge between personal knowledge management and agent automation. If you're already tracking work in Org-mode, Celorga lets you hand off tasks to agents without migrating to a dedicated orchestration platform.\n\nCelorga demonstrates how structured plaintext can serve as agent coordination infrastructure when you add the right APIs. The MCP server is a thin adapter that preserves Org-mode's simplicity while making it agent-callable.\n\nThe architecture is appropriate for personal automation and small-team workflows where eventual consistency is acceptable. For production systems with high concurrency or strict observability requirements, you'd need to add locking, validation, and instrumentation layers.\n\nThe interesting insight is that task management and agent orchestration share the same primitives: state transitions, scheduling, context passing, and execution triggers. Celorga exposes this overlap by treating TODO items as orchestration nodes.", "url": "https://wpnews.pro/news/celorga-org-mode-as-agent-orchestration-infrastructure", "canonical_source": "https://dev.to/mech_app_ai/celorga-org-mode-as-agent-orchestration-infrastructure-3nh7", "published_at": "2026-10-19 20:06:37+00:00", "updated_at": "2026-10-19 20:14:40.505249+00:00", "lang": "en", "topics": ["ai-agents", "agent-protocols", "ai-tools", "developer-tools"], "entities": ["Celorga", "Emacs", "Org-mode", "Model Context Protocol", "Claude Desktop", "Node.js"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/celorga-org-mode-as-agent-orchestration-infrastructure", "markdown": "https://wpnews.pro/news/celorga-org-mode-as-agent-orchestration-infrastructure.md", "text": "https://wpnews.pro/news/celorga-org-mode-as-agent-orchestration-infrastructure.txt", "jsonld": "https://wpnews.pro/news/celorga-org-mode-as-agent-orchestration-infrastructure.jsonld"}}