Quark Agency OS
The result
A local-first AI operations platform that connects conversation, tools, project memory, and supervised agent workflows in one operator interface.
A look at the work
The challenge
Turn model interactions into supervised workflows with persistent context, scoped tools, recoverable execution, and reviewable evidence.
What shipped
A FastAPI orchestration backend and browser control surface for local models, tool execution, mission planning, and persistent context. Local inference is supported alongside explicitly configured external providers; data handling depends on the selected workflow and provider.
- A durable tool loop saves progress, records results, supports cancellation, and stops uncertain operations for review.
- MCP capability discovery connects tool schemas to validation, scope checks, and approval policies.
- Mission planning tracks steps, revisions, capability readiness, and execution evidence for supervised agent work.
- Project memory, knowledge ingestion, and retrieval supply context across runs instead of relying on a single chat window.
- Provider routing supports local runtimes and configured external models, with usage and budget handling.
- Voice session orchestration, specialist personas, and model configuration tools sit behind the shared operator interface.
- SQLite mission records, MongoDB-backed structured state, and retrieval storage have distinct responsibilities.
Crew on this contract
Quark AI operations brings conversations, tools and project context into a supervised working environment. This case describes the implemented controls and records behind its operator interface.
From chat to supervised operations
Quark is an operator environment for model-assisted work: it brings conversations, tools, project context, and multi-step missions into a shared control surface. The difficult part is retaining useful state while distinguishing a proposed action, an attempted action, and an outcome that has evidence behind it.
The FastAPI backend runs a durable tool loop that saves progress, records results, supports cancellation, and stops uncertain operations for review. Mission records track steps and revisions separately from the side effects of executing a tool.
Tools need more than a connection
MCP capability discovery supplies schemas, but invocation also passes through validation, workspace scope, and approval rules. Readiness checks consider whether a capability is available before a mission is dispatched. Execution records then give the operator something concrete to review.
Context and models have separate responsibilities
Project memory and managed knowledge ingestion carry decisions and reference material between runs. SQLite mission records, MongoDB-backed structured state, and retrieval storage serve different jobs rather than treating every kind of information as chat history.
Provider routing supports local runtimes and explicitly configured external models, with usage and budget handling. Local-first operation is a deployment choice; it does not imply that every configured integration is offline.
A control surface for the operator
Specialist personas, voice sessions, model configuration, and mission planning sit behind the browser interface. The aim is reviewable, supervised execution with persistent context—not a claim that every project can be delivered unattended.
Related capabilities: Python and AI systems and structured operational data.
What this project clarifies
For a similar workflow, define the action a tool may take and the evidence a person needs before accepting its result. A connected tool and a completed business task are different milestones.
For a related project, see ongoing development.
Have something like this in mind?
This is the kind of build I take on. Book a call and we'll scope yours.