Orqys

Thesis

AI-native engineering operations layer. Ticket in, production-ready PR out — not a code suggestion, a deployable pull request. Decomposes the SDLC across specialized agents (context retrieval, planning, code generation, review, PR synthesis) orchestrated as a DAG. The philosophy quote that anchors the product: "The goal isn't to replace engineers — it's to compress the mechanical parts of the job so more time goes to design, architecture, and the genuinely hard decisions."

Status

active (portfolio: Building). Two artifacts exist: the product itself and orqys-playground, a live demo where users get a dedicated Slack channel and tag @Orqys to have changes appear as PRs on a public Next.js dashboard repo.

Stack

Orchestration: DAG-based workflow engine; agents run in parallel where dependencies allow.
Tool integration: Model Context Protocol (MCP) — so the system plugs into any codebase's linters, type checkers, and test runners without custom adapters.
Context retrieval: semantic search over embeddings combined with structural analysis (imports, call graphs) for focused context windows.
Validation: sandboxed execution environment for the review agent — generated code is compiled and tested before PR submission.
Playground: Next.js 15 (App Router), Tailwind v4, TypeScript, ApexCharts; Slack as the user-facing interface; Orqys opens PRs against the playground repo.

Key decisions

Multi-agent over monolithic: a single LLM call can't reliably do ticket→PR end-to-end. Scoped agents with clear interfaces produce more consistent output.
MCP for tool integration: zero custom adapters per codebase.
DAG orchestration: context retrieval and planning don't need to block each other.
Slack as the demo interface (playground): meets engineers where they already triage work, no new UI to learn.
Public demo repo that Orqys actually modifies: dogfooding as marketing — users see real PRs on a real repo.

Learnings

Context window management is the primary constraint of agent systems. Retrieval strategy (semantic + structural) is where accuracy lives or dies.
Sandboxed validation adds latency and infrastructure overhead but is non-negotiable if "production-ready" is the product promise.

Outcomes

Playground is live (orqys-playground.vercel.app).
Product described as "a bet on agent-native software development."

Open questions

Where's the wedge customer? Open-source maintainers, internal platform teams, solo builders?
What's the agent failure mode when code doesn't compile in sandbox? Retry with different plan, escalate to human, or fail the PR?
How does MCP integration scale when a codebase has a custom toolchain the public MCP servers don't cover?