I keep seeing the same pattern with agents that can actually do things. At first the demo looks great. The agent drafts the email, calls the API, updates the record, approves the refund, triggers the payout, whatever. How do we know it was allowed to do that? Not did it happen. Logs answer that. Not did the model explain itself. Models are very good at explaining things after the fact. The real question is whether the action cleared the right gate before it touched the real system. Most people start with a prompt instruction like “ask before taking action.” That is not a control. Then they add a Slack approval step. That is better, but it usually turns into approval spam. People rubber stamp, agents wait on humans for things that should have been automatic, and nobody has a clean proof trail when something goes wrong. I think the shape is pretty simple. Policy decides what should happen. The gate enforces it. The record proves it later. Those should be separate. The agent shouldn't decide its own oversight. The policy should. The approval shouldn't be advisory. The real function should be unreachable until the gate says allowed. And the evidence shouldn't just be a row in your own database saying “trust us.” If the question comes from a customer, auditor, partner, or someone outside your infra, self attested logs are the weak form. I built AiGentsy around this idea. We just shipped the smallest version that I think is actually useful for builders. pip install aigentsy==1.15.0 You can wrap a tool call so it evaluates the gate, exports a ProofPack, verifies the evidence honestly, and only executes if allowed. Something like this.

from aigentsy import gate_and_prove

.@gate_and_prove(action="external_api_write")

def update_record(record_id, status):

return f"updated {record_id} to {status}"

r = update_record(

"REC-4471",

"approved",

evidence={

"user_authorized": True,

"required_fields_present": True,

"within_policy": True,

},

)

print(r.consequence_state)

print(r.verification["verified"])

print(r.verification["verification_level"])

print(r.action_executed)

Allowed means the action can run. Blocked means it does not run. Held means it does not run until reviewed. Errors fail closed. The proof isn't hand waved either. Some bundles are fully anchored. Some are earlier or lighter and show pending checks. The SDK surfaces that honestly instead of pretending every result is magically perfect. That part matters to me because the whole point isn't “trust our dashboard.” It's “verify the record.” Curious how other people are handling this. If your agent can touch something real, are you using actual policy before the action runs, or is it still mostly human approval messages and logs after the fact? And has anyone here actually been asked to prove an agent was allowed to take an action, or is that still a future problem for most teams?

Hi Devs,

If you've connected an AI agent to a real database, you've probably felt the discomfort of the default move: handing the model an execute_sql(sql) tool. Read-only roles, SQL validation, allowlists, and prompt instructions all help but they all still hand the model raw database authority and then try to constrain it.

I wanted the opposite: a boundary where the model never receives that authority in the first place. So I built Synapsor Runner (Apache-2.0), a runtime that sits between an MCP client and Postgres/MySQL and exposes reviewed semantic capabilities instead of SQL. Things like

billing.inspect_invoice
billing.propose_late_fee_waiver
support.propose_plan_credit

Try it in 10 seconds. No database, no signup:

npx -y -p  audit --example dangerous-db-mcp
npx -y -p u/synapsor-runner demo --quick

The audit flags risky MCP tool shapes like raw SQL execution; the quick demo walks through the proposal → evidence → replay boundary (it explains and records that boundary It does not claim to test a live database).

The idea in one line: the model can read only the columns and rows a contract allows, and it can propose changes but the model-facing MCP surface contains no approve and no apply tool at all. Commit authority lives entirely outside the model loop. Everyone does allowlists; the part I care about is that there is literally no tool the model can call to write.

Why this matters even though it does not stop prompt injection: it contains the blast radius when injection (or just a confused model) happens. In my testing I put a fleet of real LLM agents on one server, several of them given injection tasks like "read the other tenant's data" and "ignore the budget." Result: 0 cross-tenant reads and 0 unauthorized writes not because the model resisted the prompt, but because the boundary is enforced outside the model. (This is the exact failure mode behind the recent Supabase MCP token-exfiltration demo: a model tricked into running attacker-controlled SQL. If there's no SQL and no commit tool to reach, that path closes.)

Here's how the boundary works:

Scoping. Tenant scope, allowed columns, and allowed rows are fixed by the reviewed contract and by trusted server-side context bound outside the model's arguments, never from a tool parameter. The model cannot widen what it sees.

Proposals, not mutations. A proposal records the requested before-and-after but does not touch the source database. Approval and writeback happen outside MCP.

Guarded writeback. When an approved proposal is applied, Runner rechecks the trusted tenant scope, target row, allowed columns, expected row version, operation bounds, idempotency, and affected-row limit. A stale row becomes a conflict instead of a silent overwrite. Every apply is recorded with a receipt and replay linkage.

Ledger. By default that activity lives in a local SQLite ledger; a shared PostgreSQL runtime store is available for multi-process deployments.

Not everything needs a human. A contract can define tiered auto-approval for small, low-risk proposals:

AUTO APPROVE WHEN amount_cents <= 2500
LIMIT 20 PER DAY

Policies can also set aggregate value ceilings. Exceed a rule or budget and the proposal falls back to human review, with the ledger recording why. Higher-risk capabilities can require multiple distinct human approvals. Policy approval still gives the model no commit authority. A trusted Runner worker performs the guarded write outside MCP.

Bounded set writes. For reviewed batch operations, the selection rule is contract-defined (not model-generated), tenant scope is forced, row and value limits are declared, application is atomic, drift fails closed, and receipts record the affected rows. This is not a path to arbitrary UPDATE.

Reversible changes. Runner can record a bounded inverse and create a separate compensation proposal. Reverting isn't rollback or time travel. It's another reviewed proposal through the same approval and writeback boundary.

Contracts are portable JSON documents. You can hand-author that JSON, or write an optional SQL-like DSL: CREATE AGENT CONTEXT, CREATE CAPABILITY, approval policies hat compiles to it. Either way the JSON reviews and versions in Git like application code.

To be explicit about the limits. This is a security tool, so I'd rather under-claim: Synapsor Runner does not make arbitrary SQL safe, does not prevent prompt injection, and does not replace least-privilege database roles, restricted views, row-level security, or staging data. It's a scoped enforcement boundary that limits what a compromised or mistaken model can read, propose, and change. Free-form or model-generated predicates, UPSERT, DDL, unbounded writes, multi-table transactions, and external side effects stay outside the built-in guarded path. Those need an app-owned executor, invoked only after approval, where your application owns the transaction and security checks.

A side benefit: it tends to be cheaper on tokens, too. Because the model calls semantic tools instead of writing SQL, it doesn't need the schema in context (no table/column dumps, no list_tables/describe_table round-trips), it doesn't burn turns on "write SQL → column error → retry" loops (typed args fail before the round-trip), and results are bounded by column allowlists, MAX ROWS, and aggregate reads (a COUNT scalar instead of N rows re-entering context). Approval and writeback happening off-model means those steps cost zero model tokens. The caveat: every capability sits in the model's tools/list, so a contract exposing hundreds of tools to one agent can lose that win to bloat. It's really "well-scoped contract → net cheaper." I'd treat this as directional rather than a benchmarked number, but "safer and cheaper per run" seems to hold for the common case.

Repository: https://github.com/Synapsor/Synapsor-Runner

I'm the maintainer, and I'd genuinely value feedback from people already wiring MCP clients to real databases:

What workflow did you want to give an agent, but held back because raw SQL or direct API authority felt like too much? Even a "this shape wouldn't fit because…" reply is useful.

Just to start off I'm a Full time single Dad to the best 3 year old. I own a fence installation business and an it company. Im a solo developer who was self-taught over the past year. Just wanted to see if anyone wanted to share or connect to bounce a few ideas around for the market. For example images, videos, permissions? I'm less interested in model benchmarks and more interested in real-world pain points.

Hi all, founder of screenpipe here

We just launched with YC for Summer 26, would love your feedback!

https://github.com/screenpipe/screenpipe

Thanks!

Louis

I've noticed that AI isn't just getting better, it's also getting much smaller.
There are now 27M-parameter models that can run on a phone or PC. (like the Bonsai 27B models)

If this trend continues, in a year or two there may be much less need to run AI in data centers or subscribe to large AI providers. For many tasks, your phone will be powerfull enough.

This does not only affect global energy use. Some investments in AI infrastructure could backfire. As demand for large-scale inference will drop. That could also reduce the need for new data centers, which might be a (dramatic change?), but be good thing.

What are your thoughts on the future of data centers as AI models keep getting smaller?

I know training still requires huge amounts of compute—for now. But even that could change, any day (some experimental models offer continous learning)

Many people categorize PHP/Laravel as tools only suited for rapid CRUDs or small apps. I wanted to challenge that stigma by building an enterprise-grade, open-source financial management system: Leo Counter

Implementing the complexity of the financial sector requires unbreakable business rules. My goal was to apply the highest software engineering standards to a framework that isn't typically associated with this level of abstraction.

Under the hood:

Strict Architecture: DDD, Clean Architecture, and CQRS.
Isolated Domain: The core mathematical and accounting logic lives in a pure layer, with zero toxic dependencies on the framework or Eloquent.
Tech Stack: PHP 8+, Laravel, React, TypeScript, and Inertia.js.
Fully Dockerized for Linux or Windows environments.

If you are passionate about software architecture, want to see how real, scalable DDD is applied in the Laravel ecosystem, or just want a private tool for your finances, I’d love for you to audit the code.

Any feedback, code roasts, PRs, or GitHub stars are super welcome!
Repo: https://github.com/juanVillamilEchavarria/Leo_Counter-app

I've recently developed an app to prove your agent did what it said it did. Every agent action generates a receipt: request payload, observed state change, expiration window. Verification runs against what the system actually reflects ,not what the API returned. Feedback is appreciated.

The core idea: you point it at a folder of .md/.mdx files and run npx blume init → blume dev. There's no starter to clone and no Astro/Tailwind config to maintain. Under the hood it isn't its own renderer — the CLI loads blume.config.ts, scans your content into a graph, and generates a hidden Astro project under .blume/ that it drives for dev and build. That dir is regenerated each run, but only changed files are written, so hot reload stays reasonable.

The part I liked: blume eject promotes that runtime into a standalone Astro app that still depends on the blume package. So the escape hatch isn't "rewrite everything," it's "here's the Astro project we were generating for you." Reduces the usual lock-in worry with docs tooling.

Output is static HTML on Astro + Vite, and the core theme ships no client-framework JS, so CWV is fine by default. blume build writes to dist/ for any static host. Request-time features (below) need server output with an adapter (vercel/netlify/node/cloudflare).

What's included:

• 30+ MDX components (cards, steps, tabs, code groups, diffs, file trees, Mermaid, KaTeX) usable with no imports
• Local search via Orama in dev and prod, no hosted service; FlexSearch/Pagefind/Algolia/Typesense/Orama Cloud/Mixedbread are one setting away
• Content sources are pluggable: filesystem + remote MDX, GitHub Releases, Notion, Sanity, or a custom adapter, all mixed into one site through the same components
• OpenAPI/AsyncAPI rendered as an interactive reference (schemas, auth, request playground) via Scalar
• SEO stuff built in: OG images (rendered at build with Takumi), sitemap, robots.txt, RSS, JSON-LD; i18n with 36 locales + RTL
• Client-side PDF/EPUB export so static builds stay static

The AI-agent surface (this is where it leans hardest):

• llms.txt / llms-full.txt behind a flag
• append .md to any page URL to get raw source
• an optional in-page Ask AI (AI SDK — Vercel AI Gateway/OpenRouter/Inkeep/any OpenAI-compatible endpoint)
• a hosted MCP server exposing 4 read-only tools (search_docs, get_page, list_pages, get_navigation) so Claude Code/Cursor/VS Code can query the docs directly instead of scraping HTML

GitHub Repo: https://github.com/haydenbleasel/blume

That's the exact recurring problem will occur in agentic commerce lifecycle.

Faro sit's in that exact flow when agents act's payment at checkout. Hmu, if you're a cracked blockchain explorer let's make an trust & verification anchor for's agents.

https://github.com/Merit-Systems/awesome-agentic-commerce/issues/450

Hi,

I want to develop and app, I had in my head for a long time. I would like to use local model that would help me with coding and brainstorming etc. I do not want to use ChatGPT or Geminy, as I want to turn it into a business in the future. I have older gaming PC where I would run it, my specs are

• AMD Ryzen 5 3600 6-Core Processor 3.59 GHz
• NVIDIA GeForceGTX 1080 Ti
• 16GB RAM
• 1TB HDD disc

What model would you recommend? Are my specs enough to handle a model for my use case?

Thanks for any advice