u/Trout_dev

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.