You are the pilot. AI is your crew. Quality is the destination.

Getting started · Documentation · Docs site · Overview · 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 development and production profiles for Kubernetes and VM/VPS (Production runbook, Security review). Read the Known limitations before deploying.

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

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 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

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.

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

The dashboard lives in the separate OpenJCockpit-frontend repository. Check it out next to this one and start it too; the two stacks find each other through the ports they publish on the host:

git clone https://github.com/OpenJCockpit/OpenJCockpit-frontend.git ../OpenJCockpit-frontend
cd ../OpenJCockpit-frontend && 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

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

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

The same pages, plus guided tutorials, are published at OpenJCockpit Docs.

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

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.

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.