u/Federal-Teaching2800

The most-upvoted posts here lately are some version of "your AI agent is already compromised and you don't even know it." Fair. An agent that runs shell commands, calls tools, and rewrites its own skills is one bad token away from rm -rf, leaking a key, or corrupting your repo.

Chimera (open-source, Apache-2.0) does exactly those scary things — so "what stops it from doing something catastrophic?" had to be answered before anything else. The actual design (all in the repo, not a promise):

1. Every action passes a trust kernel -> allow / warn / review / block.

- Deterministic lexical rules catch fixed-signature threats: rm -rf /, mkfs / dd to a device, fork bombs, chmod -R 777 /, curl ... | bash (-> human review), sudo rm (-> warn), and secret patterns (sk-..., AKIA..., PRIVATE KEY blocks -> warn).

- An optional semantic judge handles the intent-dependent cases a regex can't.

- Invariant: a benign action is NEVER hard-blocked. No rule + no judge = allow. A safety layer that blocks normal work is worse than useless.

2. The kernel gets cheaper over time. Repeated judge verdicts are distilled into cheap lexical rules, so the expensive semantic check runs less as it learns the threat surface.

3. Self-modification is gated, not free. The agent can't just rewrite arbitrary files. Skill/schedule changes pass a static validator (a constrained edit surface) and are rejected pre-execution if invalid — then it's verify-or-revert: test the change, keep it only if it passes, roll back otherwise.

4. Everything is audited (append-only log), so you can see what it did and why.

Honest limits:

- Defense-in-depth, not a force field. Prompt-injection that talks the model into a "benign-looking" harmful action is the hard, unsolved part — lexical rules catch signatures, the judge catches some intent, neither is perfect.

- It's alpha. 540+ tests, strict typing/linting on every change, but not battle-hardened in production yet.

If you build agents, I genuinely want to be attacked: reply with the command or self-edit you think slips past this and I'll show you where it's caught (or fix it if it isn't). Repo link + the exact rule set/kernel are in a comment below (this sub's rule 3). Apache-2.0.

Most agent frameworks pick one model per call. I wanted to test a different idea: for the hard steps, run a panel of different models on the same prompt, have a judge model cross-check them (consensus / contradictions / blind spots), then a synthesizer writes the final answer. A cost-aware router keeps easy and tool turns on a single fast model and only fuses when it's worth it.

Around that core I built the rest of a real agent: plan -> act -> verify-or-revert (executable evidence is the ground truth, so a strict reviewer can't discard verified-correct work), layered memory (full-text recall + a cross-session user profile + LLM consolidation of fact clusters), a governance kernel (allow/warn/block/review + a static validator for self-modification), cron and proactive jobs, an MCP client + OpenAPI-to-tool import, and an isolated subagent/crew layer that runs workers in parallel git worktrees with per-worker verify gates.

Honest status: it's alpha - Apache-2.0, self-hostable, 463 tests, mypy --strict clean - so it builds and is heavily tested, but it has no production mileage yet.

What I'm genuinely unsure about and would love this sub's take on: is fusion (panel -> judge -> synthesizer) actually worth the extra tokens and latency versus just calling one strong model? My own benchmarks are mixed - it clearly helps on ambiguous, open-ended reasoning, but on well-scoped coding tasks a single top model often matches it for a fraction of the cost. Where have you found multi-model setups actually pay off?

(Repo link in a comment, following rule 3.)