customized_agentic_system_mvp: The Agent Harness That Puts Governance Before Intelligence

A multi-LLM agent stack where every tool call passes through RBAC, rate limits, injection scanning, and human approval before execution.

8 min read • View on GitHub • More from chenyinrusi

An agent carrying a folder of read, write, and Git actions approaches a fortified checkpoint made of stacked filters. The gate inspects identity, speed, injection risk, and file path trust before anything reaches the workspace behind it. It explains that the repo treats execution as a controlled process, not a direct handoff from model to tools. — The repo’s core move is simple: the model can suggest, but the gate decides what survives.

The Gate Is the Product

Most agent demos assume the hard part is making the model clever enough to use tools. This repo makes the opposite bet: the model is the easy part, and the real system is the control plane around it.

That control plane is the Governance Gate. Every tool call is inspected before execution, with the system deciding whether to pass, block, or require approval based on role, rate, path trust, and injection risk.

A single tool request does not go straight to disk. It walks a policy pipeline that can stop it, approve it, or let it through.

Autonomy, But Only on Your Terms

The clearest operator switch in the codebase is tool_write_mode. It turns autonomy into a policy choice instead of a philosophical one.

tool_write_mode = off | block | approval | on

That is a useful frame because it lets one system serve very different risk profiles. Read-heavy workflows can stay fluid, write-heavy workflows can be reviewed, and dangerous actions can be shut down entirely.

Mode	What it allows	What it protects
off	No write execution	Everything that mutates state
block	Write attempts are denied	Accidental or runaway changes
approval	Human review before write	Sensitive paths and risky edits
on	Direct write execution	Only the checks already in the gate

A close-up control cockpit with four knobs labeled off, block, approval, and on. The same file write request passes through different lanes depending on the knob position, moving from red stop, to yellow pause, to green pass. It explains that the system’s autonomy is configurable rather than all-or-nothing. — The same action can be denied, queued, or allowed, depending on policy.

How the Stack Stays Decoupled

The repo is built like infrastructure, not a demo. The backend handles chat and streaming, the frontend renders the operator view, and the shared core keeps message roles consistent across the stack.

That separation matters because it lets the system swap models without rewriting the business logic. The governance layer, tool registry, and telemetry can stay stable while the LLM provider changes underneath.

backend/
src/core/
src/llm/
src/governance/
src/tools/
src/stats/

The architecture also makes auditability practical. Tool calls, approvals, and rate-limited events can be logged as system behavior rather than reconstructed from prompt history.

The Swappable Model Layer

The LLM layer is deliberately boring in the best way. A base interface defines the contract, and provider adapters handle the differences between OpenAI, DeepSeek, and Gemini.

Layer	Job	Why it matters
BaseLLM	Defines chat and stream contracts	Keeps the backend provider-agnostic
Adapter	Translates provider quirks	Lets each model keep its own behavior
Factory	Builds the right backend	Moves selection out of business logic
DeepSeek support	Carries reasoning content	Preserves model-specific signals without leaking them everywhere

That abstraction is the point. When model quality, pricing, or availability shifts, the system can keep the workflow intact and swap the provider instead of starting over.

Why This Is Not Just Another Agent Demo

Vendor-integrated tools like Claude Code and Codex optimize for a smooth product experience. This repo optimizes for ownership of the workflow boundary.

That difference sounds subtle until something breaks. If the model changes, the policy, memory, and execution rules still belong to you. If a tool is risky, the gate can stop it. If a path is untrusted, approval can be required once and remembered briefly without surrendering control.

System	Model support	Governance depth	Who owns the workflow logic
customized_agentic_system_mvp	Multi-model	High, with RBAC, rate limits, and approval flow	Your codebase
DeepSeek Harness	Multi-model	Framework-level extensibility	Harness layer
Claude Code / Codex	Vendor-tied	Productized but closed control plane	The vendor

That is why the repo matters even as an MVP. It shows the shape of an enterprise agent system where autonomy is earned, measured, and reversible, not assumed.

The Enterprise Shape of a Tiny Repo

The codebase already behaves like something meant to survive a longer life than any single model release. There is telemetry, a roadmap, tests, and a clear separation between policy and execution.

Governance makes the agent safe enough to use in real workflows.
Adapter patterns make model churn an implementation detail.
Audit logs and telemetry make agent behavior inspectable.
Human approval keeps autonomy inside organizational bounds.

Sources: chenyinrusi/customized_agentic_system_mvp, verified quote source, and repository files including src/governance/, src/llm/, backend/, and src/core/.