← Back to home
Part 4 of 4

From Prototype Chaos to a Sharper Creative Pipeline


← Part 3

Last time, I described Promptomat as if it was still mainly a smarter prompt builder. That undersold what is actually happening in the repo.

The real direction is much clearer now: Promptomat is evolving into a standalone-first Command Centre for multi-project, multi-agent orchestration.

Command Centre Is the Core Direction

The docs and app structure now point at one central idea: combine project knowledge, reusable workflows, service integration, and worker orchestration into one control surface.

This is already visible in the implementation shape:

So this is no longer "prompt in, output out." It is orchestration-first by design.

A Clear Control Model Before More UI Shuffling

A major implementation focus is locking in the control model explicitly:

Even in solo mode, orchestrator and worker are treated as separate conceptual roles. That sounds subtle, but it matters: the product can scale to multiple workers later without a redesign.

The planned Command Centre panel pushes this further with PI progress, sprint progress, worker state, steering controls, and direct access to next-agent briefings.

"Brain Apps" Are Specialized Surfaces, Not One Giant Screen

Another thing I got wrong earlier: this is not trying to become one overloaded monolith view.

The "brain apps" concept is already visible as distinct surfaces around a shared core:

The workspace plan describes this spatially: left for analysis/code-heavy tools, center for the active execution loop, right for creative/generative tools.

The brain metaphor is not just visual branding either. It is tied to concrete mechanics like orchestrator overlays, ring menus, brain-oriented workflows, and future lenses such as Command Centre, Arcade, Guild Hall, and Mission Control.

Memory Architecture Is Already Mature

One of the strongest parts is the three-layer memory model:

Inbox and outbox are formal interfaces, not vague folders:

The contract is strict and healthy: workers should not write long-term memory directly. Inbox/outbox is the managed transit layer between short-term execution and long-term curation.

Plan → PI → Sprint Is a Real Execution Bridge

The planning stack is also further along than I first described.

In practical terms: PI is the planning artifact, sprint folders are the execution artifacts. That bridge turns strategy into agent-runnable context.

The Workflow Loop Is Already Operational

agents.md and WORKING-CONTRACT.md define a Plan → Build → Verify → Close rhythm, and sprint workflows expand that into lifecycle execution: next-agent briefings, worker rosters, schedules, verification, archive, and cleanup.

The roadmap and active PI work show this is not theoretical. Orchestrator upgrades, sprint-close mechanics, sprint analysis, brainstorm pipeline evolution, and blog automation are already scoped as concrete increments.

Blogging Is Emerging as a Native Output of the System

One of the most interesting parts: blog writing is being designed as a byproduct of orchestration, not an unrelated marketing task.

The Sprint Analysis workflow is meant to read commit history, sprint plans, roadmap deltas, inbox change, and outbox outputs, then emit structured prose summaries, including blog-ready drafts.

The same system that runs execution is being shaped to explain execution.

Steering and Adaptive Loops Are the Next Layer

There are also active experiments around mid-run steering and adaptive loops:

The Better Summary

Promptomat is becoming an orchestration-first AI workbench where:

So yes, this post needed a correction. The direction is sharper than "prompt builder growth." It is a command-and-orchestration system that treats planning, execution, memory, and communication as one continuous loop.

← Back to home