Most tools govern what an agent can do. Solon governs whether the decision was right.
And it learns from the last time a human disagreed.
Free · we deploy it · weekly metric reviews · exit anytime
What Solon sees
Where each approach sits
Categories, not mud-slinging: every tool below is good at the question it answers. None of them answers Solon's.
| Tool | What it governs | When it acts | Learns from overrides | Produces durable policy |
|---|---|---|---|---|
| AWS Bedrock AgentCore (temporal policies) | Agent actions and tool access | Runtime, before the action | No. Approvals are required, not learned from | No. Rules are authored manually |
| Salesforce Agentforce Trust Layer | PII, prompt injection, audit logs | Runtime | No | No |
| Evaluation & observability suites | Output quality and drift | After the fact, on outputs | No. Scores outputs, not business decisions | No |
| GRC platforms | Risk registers and compliance documents | Inventory and periodic review | No | No. Documents, not executable rules |
| OPA / Rego | Infrastructure access policy | Runtime, static rules | No | No. Rules are engineered by hand |
| Spreadsheets + manager judgment | The status quo | After the fact, in people's heads | Implicitly. Then it walks out the door | No. The same case returns |
| Solon | Business decisions: refunds and exceptions | On every decision, and after every override | Yes. Overrides cluster into a proposed rule | Yes. A versioned pull request a human merges |
Based on public documentation, September 2026. If something here mischaracterizes your tool, tell us. We'll fix it.
Why not just a spreadsheet?
For most teams, the real alternative isn't a vendor. It's a spreadsheet and a manager's memory.
No versioning
The policy lives in someone's head. There's no diff, no review, no history to learn from.
No audit trail
When a decision is questioned months later, the reasoning is gone.
It walks out the door
When the manager leaves, the judgment leaves with them. Nothing compounded.
Solon turns that judgment into versioned, reviewable policy. Starting from the overrides your team already makes.
From override to policy, in four steps
Solon wraps one decision function in your app. Everything else is the loop.
Every decision, recorded
Each decision and override is stored append-only, with PII redacted per your policy. The evidence is audit-ready.
Repeats surface
Similar overrides cluster in a rolling window. Three similar cases is enough signal to propose a rule.
A rule, as a PR
Solon drafts the rule and opens a pull request against your policy repo. Policy is code; Git is the review trail.
A human decides
Your team reviews and merges. Or rejects. Merged rules apply to every future decision.
Humans stay in charge: Solon never merges its own proposals. Policy changes apply only when a person approves the pull request.
Proven in a 4-week synthetic pilot
Seeded traffic, simulated reviewers, the real stack. 4 weeks × 40 decisions/day. The loop compounds: escalations fall at constant traffic.
Synthetic partner pilot, seed 7. An internal proving ground, not a customer. Identical-seed reruns vary (acceptance 50–75%); both modes validated: local merges and real PRs. Evidence pack available on request.
Every tool answers a different question
The AI governance market is crowded. With tools answering everything except the question your policy owner asks.
| Question | Who answers it |
|---|---|
| Can the agent act, and what can it reach? | Agent runtimes & access-control security |
| Is the output good, and is it drifting? | Evaluation & observability suites |
| Is the organization documented for auditors? | GRC platforms |
| Is this decision correct. And did we learn from the last override? | Solon |
Run a 30-day pilot
We deploy Solon against your refund or exception workflow. You bring reviewers; we bring the loop and the metrics.
What we provide
- A deployed stack at your domain (TLS, your policy repo)
- Policy co-authoring from your current exceptions runbook
- Reviewer training and a calibration session
- Weekly metric reviews. The five pilot metrics, no vanity numbers
What we need
- A Git repo for your policies (private is fine)
- 2–4 reviewers (support managers)
- One integration point for your decision function
- 30 minutes a week of feedback
Free during the pilot · exit anytime · merging stays a human action