AI Orchestra

Inspiration

Teams are moving quickly from AI experiments to real systems, but the architecture work is still fragmented across diagrams, configuration files, security reviews, model choices, retrieval designs, and operational checklists. I built AI Orchestra to bring those decisions into one governed workspace that both technical and nontechnical stakeholders can understand.

What it does

AI Orchestra is a low-code AI systems blueprint orchestrator. It lets a solution architect or product team:

• compose a complete Enterprise RAG workflow on a visual canvas;
• configure nodes and distinguish executable, simulated, and roadmap components;
• validate architecture readiness before execution;
• run a governed retrieval flow with input and output guardrails;
• inspect citations, evaluator results, latency, token, cost, security, and nine-stage RunEvidence;
• block unsupported uploads, tools, connectors, unsafe exports, stale assurance, and other high-risk paths;
• download deterministic workflow JSON and an architecture-assurance Markdown report;
• start a provider-free judge path through Docker Compose without host Node, npm, Ollama, a model download, or an OpenAI API key.

The demonstration workflow contains nine nodes and eight edges. Eight nodes execute. The relational database is intentionally simulated, visibly labeled, unopened, and unqueried.

How it works

The application is built with Next.js, React, TypeScript, Zod, and React Flow. Server-side execution follows a bounded sequence: authentication, request and rate controls, architecture validation, input guardrail, bounded retrieval, exactly one generation boundary, citation validation, output protection, evaluation, and structured evidence.

The portable judge mode uses an explicitly labeled deterministic-test/ao011-judge-fixture target. It substitutes only the generation boundary while exercising the real authentication, workflow compilation, retrieval, guardrails, evidence, evaluators, citations, stale-state handling, and export paths. It is not Ollama and not live model inference. A separate optional loopback-only Ollama qwen3:4b integration remains available for live local-model validation, with no silent fallback between modes.

Security and assurance

The MVP includes deterministic controls for prompt injection, sensitive-data leakage, excessive agency, unauthorized tools, absent connector/upload surfaces, session isolation, request size, concurrency, rate limiting, denial of wallet, safe logging, secret scanning, and bounded Docker execution. RunEvidence remains in memory and contains safe fixed-code diagnostics rather than raw prompts, credentials, stack traces, or provider bodies.

The current exact-head validation reports 54 Vitest files / 381 tests, ten Chromium scenarios, one deterministic AO-011 invocation, and zero Ollama or OpenAI requests. Hosted validation exercised Docker build, quiet credential bootstrap, health, readiness before and after restart, and scoped teardown on an ephemeral Ubuntu x86_64 runner.

How I used Codex and GPT-5.6

I used GPT-5.6 in ChatGPT as the architecture and governance partner: defining the product thesis, bounded MVP, threat model, provider strategy, evidence contracts, acceptance criteria, review gates, and issue-by-issue implementation packages. I used Codex throughout implementation to inspect the repository, build each bounded slice, add regression tests, run CI gates, review exact diffs, remediate security findings, and maintain one-issue/one-branch/one-PR delivery discipline.

This separation was intentional: GPT-5.6 helped shape the system-level decisions and review framework, while Codex translated those decisions into tested TypeScript, Docker, documentation, and GitHub workflows.

Challenges

The hardest part was preserving truthful boundaries. A deterministic judge path cannot be presented as live inference; a simulated database cannot be presented as executed; a passing CI run cannot erase residual risk. The project therefore makes execution mode, provider status, simulation status, cost evidence, security findings, and unsupported capabilities explicit in both the UI and documentation.

What's next

The next step is to complete the remaining dependency-advisory remediation, merge the portable deployment branch, and expand from one governed Enterprise RAG blueprint into reusable architecture templates, approved provider profiles, human review gates, and enterprise deployment integrations.

Built With

• docker-compose
• github-actions
• gpt-5.6
• next.js
• ollama
• openai-agents-sdk
• openai-codex
• playwright
• qwen3-4b
• react
• react-flow
• typescript
• vitest
• zod