<aside> 🐆

LYNX is a local orchestration layer that connects AI/MCP clients, approved developer workspaces, and coding CLIs already authenticated on the developer machine into visible, role-based workflows.

</aside>

1. Project overview

Lynx addresses a workflow problem that appears when developers use multiple AI clients and coding CLIs: the tools can each perform useful work, but orchestration becomes difficult to understand and trust when task routing, terminal activity, file changes, approvals, and revision loops are hidden behind one generic “working” state.

Lynx adds a coordination layer without requiring one model provider to own the entire development environment.

Its primary responsibilities are:

• expose approved development workspaces to connected MCP clients;
• route work to available coding CLIs;
• organize work through explicit logical roles;
• normalize different CLI execution styles into one event model;
• surface task activity, changed files, approvals, and results;
• preserve review/revision loops instead of treating the first result as final.

2. Design goals

Visibility

A developer should be able to see which role is active, which worker/CLI owns the task, what stage the workflow is in, and what changed.

Provider independence

The orchestration layer should not require moving all development work to one model vendor. Existing authenticated CLIs remain the provider-facing execution tools.

Bounded workspace access

Connected clients operate against explicitly approved workspaces rather than arbitrary machine access.

Reviewable autonomy