alexgarden

FWIW, I chased this demon early-days in my multi-agent orchestrated harnesses. you'll need a state machine. i used locally hosted temporal.io. it's a bit of a PITA to set up but it whips the llama's ass once it's running.

Vibe coding hardware. Nice.

Super cool idea, and I like the hierarchy view - looks like SolidWorks / OnShape, but your UI's pretty flaky; it keeps chasing the solution. If you could make that part more robust, it would be more fun. I did enjoy my "anthropomorphize a unicorn taking off in flight like Superman" model. Does ordering actually work, or is this still a test?

We're building in this space so I'll share what we've learned rather than what we sell.

The fundamental problem with Article 50 compliance isn't knowing the obligations — it's operationalizing them continuously. You can read Article 50 once and understand you need to: (1) notify users they're interacting with AI, (2) mark AI-generated content machine-readably, (3) disclose how decisions are made, and (4) maintain audit trails.

The hard part is proving you actually did all four, consistently, across every agent interaction, in a way a regulator can independently verify. Documentation gets stale the moment you deploy. Logs can be edited. Self-attestation is just a trust claim.

What we've found developers actually need:

    Fail-closed defaults. If your compliance check fails or times out, the agent shouldn't silently continue. That's the gap most teams miss.
    Machine-readable marking that's actually machine-readable. Not a disclaimer in the chat window — structured metadata a regulator's tooling can parse programmatically.
    Tamper-evident audit trails. Append-only, hash-chained, so you can prove nothing was deleted or reordered after the fact. This is the difference between "we logged it" and "we can prove we logged it."
    Cross-regulation awareness. If you're in fintech, DORA and AI Act overlap. If you handle personal data, GDPR and AI Act overlap. The compliance surface is the union, not the intersection.

The teams I've seen doing this well treat it as an engineering problem from day one — SDK presets, CI/CD integration, automated conformity checks — not a quarterly legal review.

157 days isn't a lot of runway.

Yah... how does this evolve... this is the big question. Honest answer? We'll see.

My opinion? Human-in-the-loop will get thinner over time. As that happens, the accountability chain has to thicken. If we want any notion of reliable trust, these scales have to balance. Note: I don't think this scales without it.

Broadly speaking (I've talked a lot about life in the post-rules universe), we (humans) stop signing actions and start signing policies - policies in this case are declarative envelopes of defined agent automation boundaries.

Couple this with a proof system that can (cryptographically) prove that the agent stayed between the lines.

Build on that... trust between agents becomes computable. If A trusts B, you have a derivable trust score (with ~ decay) and naturally Quorum models fall out of that.

Then you get to proof composition - essentially "instead of verifying /checkpoint you verify a proof for an entire session - the math guarantees nothing was skipped. Human only needs to see the summary.

All of this presumes the policy was correct to begin with. This approach isn't a substitute for "don't write sloppy policy or be an asshole."

Hey! I launched AAP and AIP via Apache specifically because I want independent implementations built on top of them. I have a pretty killer roadmap of new features for both protocols coming out that will keep them on the bleeding edge. Love to see what you come up with.

On standards, I totally agree. There are those who will disagree, but my view is that we are rocketing towards a post-internet agent-to-agent world where strong and reliable (and efficient) trust contracts will be the backbone of all this great new functionality. Without that, it's the wild west. AAP and AIP are extensions of Google's A2A protocol. FWIW, I have submitted papers to NIST, the EU AI Act's section 50, written alignment cards for the WEF standards proposals, and have an AAIF proposal ready as well. Need to find the time to get on their calendar and present. That was the whole point of the hosted gateway approach. Trying to reduce the friction of using this to one line of code.

On the point of not trusting the LLM, you're preaching to the choir. My "helpful" agents routinely light my shit on fire. AIP is not a soft instruction set. It's external to the agent. checkIntegrity() is code, not a prompt. The way I implemented it with smoltbot is a thinking-block injection that nudges the agent back on track. That's all, live on our website using our AI journalist as dogfood.

On the last part, who watches the watchman, I'm going to append to my initial post. Check this out...

You're welcome - and thanks for that. Makes up for the large time blocks away from the family. It does feel like potentially the most important work of my career. Would love your feedback once the new showcase is up. Will be tomorrow - preflighting it now.

Not a dumb question — it's the right one. "Who watches the watchmen" has been on my mind from the start of this.

Today the answer is two layers:

The integrity check isn't an LLM deciding if it "feels" like the agent behaved. An LLM does the analysis, but the verdict comes from checkIntegrity() — deterministic rule evaluation against the Alignment Card. The rules are code, not prompts. Auditable.

Cryptographic attestation. Every integrity check produces a signed certificate: SHA-256 input commitments, Ed25519 signature, tamper-evident hash chain, Merkle inclusion proof. Modify or delete a verdict after the fact, and the math breaks.

Tomorrow I'm shipping interactive visualizations for all of this — certificate explorer, hash chain with tamper simulation, Merkle tree with inclusion proof highlighting, and a live verification demo that runs Ed25519 verification in your browser. You'll be able to see and verify the cryptography yourself at mnemom.ai/showcase.

And I'm close to shipping a third layer that removes the need to trust the verifier entirely. Think: mathematically proving the verdict was honestly derived, not just signed. Stay tuned.

Yep... fair question.

So AIP and AAP are protocols. You can implement them in a variety of ways.

They're implemented on our infrastructure via smoltbot, which is a hosted (or self-hosted) gateway that proxies LLM calls.

For AAP it's a sidecar observer running on a schedule. Zero drag on the model performance.

For AIP, it's an inline conscience observer and a nudge-based enforcement step that monitors the agent's thinking blocks. ~1 second latency penalty - worth it when you must have trust.

For both, they use Haiku-class models for intent summarization; actual verification is via the protocols.

The short version: instructions tell the model what to do. An Alignment Card declares what the agent committed to do — and then a separate system verifies it actually did.

Most intent/instruction work (system prompts, Model Spec, tool-use policies) is input-side. You're shaping behavior by telling the model "here are your rules." That's important and necessary. But it's unverifiable — you have no way to confirm the model followed the instructions, partially followed them, or quietly ignored them.

AAP is an output-side verification infrastructure. The Alignment Card is a schema-validated behavioral contract: permitted actions, forbidden actions, escalation triggers, values. Machine-readable, not just LLM-readable. Then AIP reads the agent's reasoning between every action and compares it to that contract. Different system, different model, independent judgment.

Bonus: if you run through our gateway (smoltbot), it can nudge the agent back on course in real time — not just detect the drift, but correct it.

So they're complementary. Use whatever instruction framework you want to shape the agent's behavior. AAP/AIP sits alongside and answers the question instructions can't: "did it actually comply?"

Close but not quite — it's not re-steering the model. AIP doesn't modify the agent's behavior or inject corrections back into the context. It's a passive observer that reads the thinking trace and produces a verdict. What happens after the verdict is up to the operator — you might block the action, escalate to a human, log it, or let it through with a flag.

Think of it less as a feedback loop and more as a conscience that watches but doesn't control. The agent doesn't know AIP is there (by design — if the agent knows it's being watched, you change the behavior you're trying to observe).

Benchmarks are actually coming shortly along with proofs. Noted on model outputs. FWIW, 90% of what I wrote here was me typing BUT using grammarly on my cleanup.

[EDIT] - overly specific answer. AIP doesn't re-steer, but our gateway implementation smoltbot does re-steer. That was our choice of how to implement AIP.

Ha! That's a first-world problem. Check out github.com/mnemom/docs which you'll be able to access at work if you just can't wait. docs.mnemom.ai is way easier to use.

Yes — and it's a deliberate architectural decision that AIP is not itself a policy engine.

Policy engines (OPA/Rego, Cedar, Casbin) are excellent at "given this action, is it permitted?" That's a solved problem. What's not solved is "what is the agent considering doing, and does that align with what it committed to?"

AIP operates one layer deeper — it reads the reasoning trace between turns and compares it to the Alignment Card. The output is a verdict (clear / review_needed / boundary_violation) with structured concerns. That verdict can feed into a policy engine as a signal. You could absolutely wire AIP → OPA and have OPA make the final enforcement decision based on the integrity checkpoint plus whatever other policy context you have.

The Alignment Card itself is intentionally simpler than a full policy language — it's JSON with permitted actions, forbidden actions, escalation triggers, and values. That's a feature, not a limitation. It's what the agent commits to, not the full organizational policy tree. The organizational policy tree lives in your policy engine. The Alignment Card lives with the agent.

So the short answer: we integrate with policy engines rather than replace them. AIP tells you what the agent is thinking. Your policy engine decides what to do about it.