OpenJCockpit

The open-source AI Software Factory

Orchestrate AI agents. Govern development workflows. Build enterprise-grade software.

Getting started · Documentation · Docs site · Contributing

OpenJCockpit is an open-source AI Orchestration Dashboard and platform for governed agentic
software development. Instead of one AI assistant writing code in isolation, OpenJCockpit runs
teams of specialised AI agents (business analyst, solution architect, software developer, QA
engineer) through specification-driven workflows, with policy checks, human approval gates and
reviewable Git delivery built in.

It is the orchestration and governance layer around agentic software engineering: you decide what gets
built, which agents may do what, and where a human must approve. The agents do the work in a branch you
review.

Status: active development. Java application development is the primary focus. The repository
ships a local Docker Compose stack for evaluation and development. It is not yet production-hardened;
see Known limitations.

Why OpenJCockpit?

Coding agents are good at producing code. Shipping software that a team can stand behind takes more:
clear requirements, a sound design, coordinated implementation, tests, review, policy and controlled
delivery. Without structure, AI-generated changes are hard to trust, hard to trace and hard to govern.

OpenJCockpit brings these activities together:

• From AI-assisted coding → to orchestrated AI software engineering
• From individual agents → to coordinated development workflows
• From unstructured prompting → to specification-driven engineering
• From autonomous code generation → to governed, reviewable delivery

What makes it different

How it works

flowchart LR
    A["💡 Idea or<br/>requirement"] --> B["📐 Spec<br/>(Business Analyst)"]
    B --> C["⚙️ Workflow run<br/>Architect → Developer → QA"]
    C --> D{"🙋 Approval gate<br/>(optional)"}
    D -- "accept with comments" --> C
    D -- accept --> E["🌿 Reviewed branch<br/>with checkpoints"]
    E --> F["✅ Pull request<br/>and merge"]

1. Describe a feature in a prompt. Create spec from prompt has the Business Analyst agent turn it
   into a small, testable spec in your repository.
2. Run a workflow on that spec. Implement spec chains the Solution Architect, Software Developer
   and QA Engineer agents; Realise spec (code) adds the Business Analyst in front. OPA checks the start
   and every tool call.
3. Decide at approval gates, if you added them: accept, deny, or send the agent back with comments.
4. Review the result: a dedicated Git branch with the agents' changes and a checkpoint commit for
   each agent's output. Open the pull request and merge through your usual process.

Runs that are not bound to a repository record the agents' outputs on the run instead of writing files.
Default workflows do not open pull requests or merge on their own. → Default workflows

The AI Orchestration Dashboard

The dashboard is where engineers and leads coordinate AI-driven development:

• Select a project and its repository, and manage Git credentials.
• Design workflows: pick agents from the catalogue (local or A2A), order them, and add approval gates
  and workflow orbs. Group workflows, then export or import them as JSON.
• Run and observe: start workflows (with a prompt when needed), follow agents live, read their
  outputs, events and policy decisions, and see the resulting branch.
• Decide: review the approval context, including changed files, and accept, deny or comment.
• Manage specs and queues: browse specs, initialise the spec structure, create specs from prompts and
  queue specs per project.
• Explore skills and agents in the Skills Hub and agent catalogue.

→ Dashboard overview

Example: adding a feature to a Java application

Your team maintains a Spring Boot service and needs a leave request approval feature.

1. In the dashboard you select the project. You click ✨ Create spec with prompt and describe the
   feature. The Business Analyst agent drafts a spec with acceptance criteria, and you review it.
2. You start Implement spec on the new spec. The Solution Architect proposes the design. The Software
   Developer reads the relevant code and writes the changes and tests in the run's branch. The QA
   Engineer checks them against the acceptance criteria.
3. An approval gate you added after the developer lets your tech lead read the changed files and send the agent back
   once with "use the existing audit service".
4. The run finishes with a branch containing the code, tests and every agent's output as checkpoint
   commits. Your team opens a pull request, CI runs, and a human merges it.

Every step is visible, policy-checked and traceable in Git.

Getting started

Prerequisites: Docker with Docker Compose, Ollama running on the host with
qwen3.6:27b pulled, and an OpenAI API key (required to boot; some model aliases and embeddings use
OpenAI).

ollama pull qwen3.6:27b              # on the host; keep Ollama running
cp .env.example .env                 # then set OPENAI_API_KEY in .env
docker compose up --build

Open http://localhost:4000 and sign in with a seeded local user (for example tony / Welkom01!).
All seeded credentials are local-development-only examples.

→ Full guide: Quickstart ·
LLM setup ·
Authentication ·
Troubleshooting

Architecture

flowchart LR
    D["Dashboard<br/>(React)"] --> AC["ai-control-service"]
    AC --> EA["embabel-agent-service<br/>(workflows, catalogue, policy)"]
    EA --> OPA["Open Policy Agent"]
    EA <-- "internal API" --> RT["embabel-agent-runtime<br/>(agent execution)"]
    RT --> L["LiteLLM gateway"]
    L -- "A2A" --> RT
    L --> M[("Ollama / models")]
    L --> G["git-mcp-server"]
    G --> R[("Git repository")]
    K["Keycloak"] -.-> D & AC & EA & RT

OpenJCockpit is Java-first: it is built in Java and focused on Java application development. Agents,
skills and tools are configuration that operates on repository files, so other languages are a natural
extension point. They are not yet a verified target. → Architecture

Documentation

Looking for a section of the previous README? See the
documentation migration map.

For AI assistants, llms.txt gives a compact project summary and a curated index of
these documents.

Security and current limitations

OpenJCockpit is designed to support governed AI-driven software engineering. The stack in this
repository is a local development environment: it uses publicly known seed credentials, exposes the
Docker daemon to a service, and has only coarse-grained authorization, among other limitations. Do not
deploy it to a shared or production environment without your own assessment and hardening.

• Security considerations
• Known limitations
• Found a vulnerability? Please report it privately; see SECURITY.md.

Community and contributing

OpenJCockpit is open source under the Apache License 2.0 (see also NOTICE).
Contributions are welcome: bug reports, ideas for agents and workflows, documentation and code.

• Read the contribution guide and the Code of Conduct.
• Report bugs or propose features in GitHub Issues.
• Set up your environment with Local development.

If OpenJCockpit is useful to you or you like the direction, try it, share feedback, and give the
project a ⭐ on GitHub. It helps others discover governed agentic software development.