u/Trout_dev

Been building agent-contracts - a governance layer for n8n workflows - for a while. Just shipped two things worth sharing here since a few people asked about the n8n implementation last time.

What shipped :

1. Runtime declarations - no contract.yaml file required

Previously every n8n workflow needed a hand-written contract.yaml. That falls apart for dynamic workflows or third-party integrations. Now you can declare governance at runtime:

enforcer = ContractEnforcer.from_declaration({

"node_id": "email-sender-v1",

"permissions": ["email.read", "email.draft"],

"side_effects": ["email.send"],

"approval_points": ["email.send"],

"lifecycle": "triggered"

})

Same enforcement. Same audit log. Same gate behavior. No file needed. Any agent without a declaration defaults to read-only with explicit approval required on every action.

2. Contract Registry - versioned, permanent, queryable

Every contract that loads registers into an append-only versioned store.

registry = ContractRegistry()

enforcer.register(registry)

# Query exactly which contract version was active at any timestamp

entry = registry.get_at_time(

"email-sender-v1",

"2026-09-10T14:30:00Z"

)

Old versions are never deleted. The audit trail is always complete.

3. Cryptographic sealing

Every contract is hashed on load. If the contract.yaml gets edited after the workflow starts, ContractTamperError fires and the workflow stops rather than silently running under modified rules.

What's in the repo

Three n8n implementations: duplicate issue detector, competitor changelog watcher, job application rejection detector - all with contract.yaml files, scyvera enforcement, and the gateway layer wired in. 128 tests passing. MIT licensed. (22 ⭐ | 6 Forks )

GitHub: github.com/Skull-boy/agent-contracts - pip install scyvera

Happy to answer questions about wiring this into existing n8n workflows or adapting the contract schema for specific use cases.

Two weeks ago I posted Finley here - got 57 upvotes, some kind comments, a few stars. Felt good.

Then a stranger DM'd me: "how do I set this up?"

I sent them the README link and waited.

They never replied.

I went back and read the README myself. Here's what I'd been asking of normal people who just want to track stocks:

1. Fork the repo
2. Create a bot via BotFather
3. Get 3 Gemini API keys (needs 3 separate Google accounts)
4. Get a Finnhub key
5. Install Docker, spin up MongoDB + Qdrant locally
6. Create a GCP OAuth project, set up a consent screen
7. Generate a Fernet encryption key
8. Deploy to Render

Step 1 through 8. Before you've asked the bot a single thing.

I'd built a tool to help people understand their money and hidden it behind the kind of setup that requires a senior developer. I'm a third-year CS student who got annoyed that every finance bot was a glorified ChatGPT wrapper - and somehow I'd made mine worse to get started than all of them.

So I did an honest audit. Found 21 issues in my own code. Some of them were embarrassing:

OAuth state was a raw user_id in the URL. Replayable. I'd shipped that live.

User tokens were stored unencrypted in MongoDB. Also live.

/docs was open in prod. The disconnect handler deleted the DB record but didn't revoke the Google token — the token kept working indefinitely after the user "disconnected."

I fixed all 21. 2,937 lines added. 130 tests (all offline, no API keys needed in CI). Fernet encryption, HMAC-signed OAuth state with 10-minute expiry, sliding window rate limiting, GDPR /delete_my_data that hard-deletes everything including Qdrant vectors, prompt injection detection, Redis-backed quote cache so one Finnhub call serves 100 users for 60 seconds.

And I killed the requirement for users to supply any API keys at all. Server-side Gemini pool. One GCP project I own. User hits /start, clicks an auth link, done.

Honest current state: the zero-config hosted version isn't live yet. You still have to self-host. The upgrade plan is done, the hardening PR is merged, the hosted deployment is next. I'm posting this before it's finished because that's apparently what I do.

The thing I didn't expect: auditing your own project after people have started watching it hits differently than auditing your own hackathon throwaway. Different stakes, different mindset. Found myself thinking about data I'm responsible for, not just data I'm playing with.

Still built entirely on free tiers. Still MIT licensed.

Repo: github.com/Skull-boy/Finley

What would actually make you trust a bot like this with your real watchlist? I have a guess but I want to hear it from people who aren't me.

so some context. I've been maintaining this small open-source project for a while now called agent-contracts. the whole premise is kind of embarrassingly simple in hindsight - MCP standardized how agents talk to tools, A2A standardized agent-to-agent comms, but nobody standardized what an agent is allowed to do. so that's what the repo tries to be. governance spec. contract.yaml per workflow. declare your permissions, side effects, approval boundaries, recovery semantics upfront.

anyway. I went down a rabbit hole reading the Prime Agent codebase and the Continual Harness paper (2605.09998) and now I genuinely cannot think about anything else so I'm posting here at whatever time it is.

here's the thing that's stuck in my head:

Prime Agent has this /refine command - it reads an 80k char trajectory slice, a background LLM call proposes the smallest evidence-backed CRUD edit to the agent's own harness state (prompts / memories / skills / subagents), validates it, applies atomically, logs everything to a refinements.jsonl. that's genuinely cool. it's the first system I've seen where the harness itself is a first-class versioned artifact the agent can CRUD from its own trajectory. not just "hey remember this" - actual structured state management for self-modification.

but then I hit this note in the architecture docs that basically says:

--> refinement is proposal-based, not evaluation-based. it records outcomes but has no automated verification that an edit improved task success

and that's the hole. the human-review point. the eval gate that never got closed.

SICA (different paper, 2025) plugs this differently - it benchmarks re-evaluates after every self-edit to the agent script, only keeps the edit if metrics actually improve. works but requires benchmark infrastructure per task domain. kind of heavyweight.

what if the contract itself is the eval gate?

like - instead of "did this refinement improve task performance" you ask "does this proposed harness edit violate the agent's own declared governance constraints for self-modification?" the contract becomes the invariant. if the edit passes the contract, and the outcome tracking shows positive signal, promote it. if it regresses on any declared contract invariant - rollback. no external benchmark infra needed.

I've also been slowly building something called ContextBridge (different project, very unfinished) - basically version control for AI context across a whole team of specialized agents. and the thing I keep running into is that evolution of agent behavior probably isn't a per-agent problem in production, it's a per-team problem. the harness that evolves needs provenance tracking across multiple specialized roles (reviewer, executor, evaluator). which is... kind of what the contract layer already tracks.

so the rough idea is something like:

1. harness state as CRUD (prime agent already gives this)
2. every self-modification attempt is itself governed by a contract (what CAN the agent change about itself, what requires external approval, what's immutable)
3. the contract eval IS the verification gate instead of a benchmark
4. outcome tracking builds statistical confidence per memory/skill entry - deprecate what's stale, promote what works
5. multi-agent co-evolution: harness evolution is coordinated at the system level, not per-agent

I don't have a build plan yet. this is very much "3am shower thoughts" territory.

the thing that makes me uncertain:

isn't this circular? the agent decides its own contract = the agent grades its own homework. if the contract for self-modification is itself part of the harness state, what stops the agent from editing the contract to always approve its own edits. SICA avoids this by keeping the eval external. i'm not sure my version does.

also practically - I run a quantized 8B locally (Hermes on Q4_K_M, 6GB VRAM card). I'm genuinely skeptical a model that size can reliably self-modify governance constraints without hallucinating a bad edit. like the reasoning required to evaluate "does this proposed skill edit violate my declared side-effect boundaries" seems to need something stronger than what I've got running at home. has anyone done this with smaller models? does it just... not work below a certain capability threshold?

questions I'd actually like to hear thoughts on:

1. is contract-as-eval-gate circular / is there a way to break the circularity without going external benchmark
2. has anyone combined Prime Agent style structured harness state with formal permission contracts (not just prompt memory, actual typed contract CRUD)
3. for the multi-agent case - does harness evolution need to be consensus-driven across sub-agents or is orchestrator-decides-for-the-team fine

not claiming any of this is novel. would genuinely love to know if I'm late to something that already exists.

for context on the contract layer I keep referencing - https://github.com/Skull-boy/agent-contracts is the repo, MIT licensed. also on PyPI (pip install agent-contracts) if you want to run agent-contract validate against an actual contract.yaml and see what the spec looks like in practice. v0.1.0, structural validation only - I'm deliberately not overclaiming what it does.

okay so yesterday I posted about this thing I built - a Telegram financial analyst - mostly expecting 3 upvotes and maybe a comment saying "cool project."

29K views. 9 GitHub stars. 31 comments.

I'm still a little confused honestly.

but the comment that got me was someone pointing out I use too many em dashes. and another person saying I probably wrote the post with ChatGPT. which is - and I realize the irony here - exactly the kind of thing you'd say to someone who built an AI bot. fair. genuinely fair.

here's the thing though. I did not write it with AI. I wrote it at like 1am slightly panicking about whether anyone would care. the em dashes are just how I write. I've been told this before and I keep doing it anyway because I don't know how to stop.

anyway.

the comment that actually messed with my head was from u/madisonlawnguy who runs production n8n workflows and pointed out that for heavy PDF earnings reports, asyncio.create_task isn't enough - I need a proper async queue or the Telegram webhook will timeout. he's right. I hadn't stress tested that at all. I was so focused on the gateway and memory layer that I just... didn't think about what happens when someone throws a 200-page 10-K at it.

so that's what I've been doing today instead of sleeping. fixing that.

also someone asked for IPO watchlist alerts - "I shouldn't have to remember to check, it should just tell me when it's live." that sentence broke my brain a little because that's literally the whole point of what I'm building and I hadn't thought to apply it there. SEC EDGAR already has the S-1 data. it's just a new job. adding it.

I don't really have a neat conclusion here. the project page is github.com/Skull-boy/Finley if you missed yesterday's post. still MIT licensed, still zero paid APIs.

I guess I just wanted to say - the criticism was more useful than the upvotes. which feels like a weird thing to admit but it's true.

also to the person who said I write like an AI: I asked an AI to read my code and it found a security hole in my OAuth flow that I'd missed for weeks. so maybe we're even.

https://preview.redd.it/1e4bo67e2ekh1.png?width=1118&format=png&auto=webp&s=13ad7188ead36c67da58e7ad9ec9fc9f89045cef

Okay so context: I'm a second-year CS student, and a few weeks ago at a hackathon I got annoyed that every "AI stock bot" I tried was either a glorified ChatGPT wrapper that hallucinated prices, or a dashboard nobody actually opens. So I built Finley instead — no dashboard, no commands, you just... talk to it in Telegram like you'd talk to an analyst friend who never sleeps.

Send it a ticker, a voice note, a PDF of an earnings report, a screenshot of a chart — it pulls live data from Finnhub/yfinance/SEC EDGAR, remembers what you've asked before (actual vector memory, not just chat history), and can proactively DM you a morning briefing or a price alert without you asking.

The part I'm genuinely proud of: it runs on 100% free tiers. Gemini with multi-key rotation across accounts (auto-detects rate limits, rotates keys, retries — never just dies), MongoDB + Qdrant free clusters, zero paid APIs. I wanted to prove you could build something that doesn't feel like a toy without spending a dollar.

I'm posting this half-nervous, honestly — I know finance-bot posts get torn apart here (rightfully, most of them are trash), and I fully expect someone to poke a hole in the alert latency or ask why I didn't just use LangGraph. Go for it, that's kind of why I'm here. Would rather find out now than after more people are relying on it.

It's open source, MIT licensed.

What would you actually want out of something like this before you'd trust it with a real watchlist?

Repo's here: github.com/Skull-boy/Finley

I originally started this project with a pretty simple idea:

Let people build agentic workflows, share them, reuse them, and contribute their own.

I thought the main problem was making workflows easier to distribute and collaborate on.

Then I started thinking about something much more uncomfortable.

What actually happens when an agent executes something you don't fully trust?

A model/SLM.
A binary.
A signed artifact.
A tool.
An external resource.

You can give an agent something and tell it:

>

But if that thing is effectively a black box, how much do we actually know?

• What is it allowed to access?
• What permissions does it have?
• What can it modify?
• What side effects can it create?
• Where does the data go?
• Can we stop it?
• What happens when it fails?

I recently came across a discussion/video around trojanized SLMs and malicious model artifacts, and that pushed this thought even further.

Maybe the problem isn't the workflow itself.

Maybe we need a contract around the workflow.

Something that can describe the expectations, boundaries, permissions, inputs, outputs, side effects, governance, and recovery expectations around an agentic workflow — while leaving the actual implementation flexible.

And here's where Reddit actually changed the project.

I started discussing the original workflow idea with people here, and some of the criticism made me rethink the whole abstraction.

After a lot of back-and-forth, I moved away from:

“Let's standardize and share workflows.”

towards:

“Let's define the contract that a workflow/agent should operate under.”

That eventually became Agent Contracts, and I've now released the base implementation as Scyvera.

It's very early.

I'm not claiming this is the solution to agent governance. In fact, I'm pretty sure there are things I've got wrong.

That's partly why I'm putting it here.

I'd genuinely like people to poke holes in it.

Is the contract layer actually useful?
What should belong in a contract?
What shouldn't?
Am I abstracting the wrong thing again?
How would you approach this differently?

If the idea makes sense, build on it.

If you think it's bad, tell me why.

If you see a completely different direction, I'd love to hear it.

The project changed because of community feedback once. I'd like the next version to change because of it too.

GitHub: https://github.com/Skull-boy/agent-contracts

PyPI: https://pypi.org/project/scyvera/

A week ago this repository was basically what the name said: n8n_workflows.

A collection of automation JSONs, READMEs, and a contribution guide.

Then people here started poking holes in the idea.

One person asked about output schemas. Someone else brought up dependencies. Then replay semantics and idempotency. Then verification. Then ownership. Then the question that changed how I was looking at the whole thing: if the same workflow pattern can exist in n8n, LangGraph, plain code, or something else entirely, why am I treating the n8n file as the reusable artifact?

I don't think it is anymore.

The reusable thing seems to be the behavioral shape underneath it.

detect → judge → approve → act

or

fetch → classify → route → notify

The implementation can change. The guarantees shouldn't.

So I tore apart the repository around that idea.

It's now called agent-contracts, and the structure is moving toward three separate layers:

Pattern — the framework-independent behavior being implemented.

Contract — the concrete promises made by one implementation.

Implementation — n8n today; potentially LangGraph, Make, plain code, or something else later.

The part I'm most interested in is the Contract.

The current v1 draft requires an implementation to declare its inputs and outputs, exact permissions, side effects, human approval boundaries, recovery strategy, replay semantics, dependencies, persistent state, and observability.

And every implementation can carry the same thing as contract.yaml.

Not because YAML magically makes an agent safe.

It doesn't.

The experiment is whether these declarations can eventually become checkable.

If a contract says:

github: issues:write

but the implementation contains a node capable of modifying repository contents, tooling should be able to call bullshit.

If a workflow claims to be idempotent but creates duplicate state when replayed, same thing.

If it claims an irreversible operation requires approval but the execution graph contains a path around that gate, same thing.

There is no linter doing this yet. That's deliberately not being hidden. v1 is currently the schema that such tooling could validate against later.

And this is where I'd rather have people disagree with the design than star it.

Maybe ten fields is already too many.

Maybe observability belongs in an operational contract instead.

Maybe permissions need allow/deny semantics.

Maybe replay semantics can't reasonably be represented as one field.

Maybe contracts should describe transitions rather than workflows.

Or maybe this entire abstraction already exists somewhere and I've just given it another name.

That's the useful discussion.

The repo now contains the draft Workflow Contract Spec, concept docs for permissions / side effects / approval boundaries / replay semantics / recovery, a framework-independent pattern layer, real n8n implementations, and the beginnings of an RFC process where changes have to survive a real workflow before they enter the spec.

I'm deliberately building the specification from implementations upward instead of designing a beautiful schema in isolation.

So break v1.

Find a real agentic workflow that this contract cannot describe cleanly.

That's probably more useful to the project right now than another workflow contribution.

Repo: agent-contracts on GitHub

A few days ago, I posted here about a pattern I'd been noticing: AI automation workflows keep getting rebuilt from scratch. Different tools, different frameworks, but surprisingly similar architectures hiding underneath.

I expected people to disagree.

Instead, something much more interesting happened.

As the discussion grew, engineers from completely different backgrounds started describing the same missing idea—but using entirely different language.

One person called it behavior contracts.

Another described type safety for agent interactions.

Someone building an AI operating system talked about authority, governance, memory packets, and workflow execution.

Another suggested a registry of composable task blocks with explicit input/output schemas.

Someone else argued that reusable workflows aren't really reusable until they're trustable—with provenance, permissions, and reviewability built in.

Different words.

Different implementations.

The same architectural gap kept appearing over and over again.

That was the interesting part.

It wasn't that people agreed with me.

It was that they independently converged on the same abstraction without ever coordinating with each other.

Reading through all those comments made me realize something uncomfortable.

Most of our workflows communicate intent through README files and documentation. Humans can read them, but machines can't reason about them.

A README explains what a workflow does.

It doesn't define what it's allowed to do.

Those are two very different things.

So instead of continuing to debate the idea in the abstract, I tried writing the smallest version that could possibly work.

Not another framework.

Not another specification.

Just a tiny contract attached to a workflow.

Version 0 only describes four things:

• Inputs
• Permissions required
• Side effects
• Recovery behavior

Maybe those are the wrong four fields.

Maybe there should be six.

Maybe this whole direction is flawed.

But I'd rather have something concrete that people can criticize than another hundred comments arguing about an idea nobody has implemented.

The collage below is made entirely from comments on the previous thread. Every highlighted idea came from someone different, yet they all seem to point toward the same missing layer in AI automation.

I've pushed the first draft here:

https://github.com/Skull-boy/n8n_workflows

If you commented on the last thread, this is a direct response to what you wrote—not a coincidence.

And if I'm missing something obvious, I'd genuinely like to know.

What's the first field you'd add to a workflow contract that isn't here yet?

Every founder says they "keep an eye on the competition."

Some check every morning. Some pretend they don't, then end up reading changelogs at 1 a.m. anyway.

Different founders. Same workflow.

We built dashboards for revenue. We built dashboards for churn. We built alerts for production incidents.

But somehow, "Did our competitor just ship something that actually matters?" is still a browser tab, a bookmarked changelog, and a weekly ritual.

Every week it's the same thing:

• Another changelog page.
• Another Slack message: "Did you see they launched X?"
• Another hour spent reading updates that have nothing to do with your product.

RSS solved collecting updates years ago.

Collecting updates was never the hard part.

Deciding which updates deserve your attention is.

A competitor ships 40 changes this month.

Thirty-nine are irrelevant.

One might completely change your roadmap.

That's the signal you're actually looking for.

So instead of building another competitor tracker, I built something that treats this as a relevance problem.

It watches competitor changelogs (RSS or web pages), compares every new update against your own product's feature set, scores how relevant it is, and only surfaces the updates that actually deserve attention. The workflow supports both RSS and webpage sources, keeps state so updates aren't reported twice, and sends a single digest instead of a stream of notifications.

Maybe the scoring won't generalize to every product.

Maybe people will disagree with the threshold.

That's exactly why I open-sourced it.

I'd rather discover where the idea breaks in public than keep refining it alone.

If you've built a better way to monitor competitors—or think this approach is fundamentally wrong—I'd genuinely like to hear it.

Repository:
https://github.com/Skull-boy/n8n_workflows

#We're drowning in competitor updates. We're starving for competitor signals.

Every week I see dozens of posts like:

>

Then...

• No JSON.
• No documentation.
• No repository.
• No way for anyone else to learn from it.

Open source is one of the biggest reasons software engineering has evolved so quickly. I think automation should work the same way.

That's why I started publishing every generic workflow I build instead of leaving it in a private folder.

We have millions of open-source libraries.

But when it comes to automation, most workflows disappear into private client projects, Notion pages, Discord threads, or YouTube videos. That feels like a missed opportunity.

Imagine if reusable n8n workflows were as easy to discover as npm packages.

That's the direction I'm experimenting with—building a community-driven, MIT-licensed open-source repository of practical n8n workflows that anyone can fork, improve, and reuse.

Maybe it stays small.
Maybe it grows into something the community builds together.

Either way, I'd rather build it in public than keep another folder of private JSON files.

If you've built a reusable workflow, I'd love for you to contribute. Whether it's a new workflow, better documentation, bug fixes, or ideas for improvement—every contribution helps make the ecosystem stronger.

Repository:
https://github.com/Skull-boy/n8n_workflows

⭐ Star it if you find it useful.
🚀 Open a PR if you'd like to contribute.