tonyhb

It looks like Agents are less about DAG workflows and fully autonomous "networks of agents", but more of a stateful network:

* A "network of agents" is a system of agents and tools

* That run and build up state (both "memory" and actual state via tool use)

* Which is then inspected when routing as a kind of "state machine".

* Routing should specify which agent (or agents, in parallel) to run next, via that state.

* Routing can also use other agents (routing agents) to figure out what to do next, instead of code.

We're codifying this with durable workflows in a prototypical library — AgentKit: https://github.com/inngest/agent-kit/ (docs: https://agentkit.inngest.com/overview).

It took less than a day to get a network of agents to correctly fix swebench-lite examples. It's super early, but very fun. One of the cool things is that this uses Inngest under the hood, so you get all of the classic durable execution/step function/tracing/o11y for free, but it's just regular code that you write.

Their syntax does look strikingly similar to the API we launched with a couple of years ago: `ctx.run("id", () => {})` vs `step.run("id", () => {})`.

It's good to see the ecosystem form around the APIs we've developed. From feedback we've received, they're easy to use.

It's already planned, and rushing out a legal change on a Friday night ahead of plans is less than ideal.

There might be a bit of misunderstanding on what's in that git repo here. It actually contains the executor, state store, queue, and our production UI, plus the syncing, registration, and logic for functions.

Earlier this year we didn't want folks to roll their own production cloud due to queueing migrations. It would make your life hard. We're entirely responsible for that right now, as we discouraged self hosting.

That's actually coming to a close, and we'll make it easy to spin up prod clusters using this code and eg. MemoryDB, Dragonfly, or what have you.

Answered this in depth here: https://news.ycombinator.com/item?id=41605220

The TL;DR is both us and Temporal help with durable execution. We layer on events and a differing DX to make things easier, faster, and to also work on serverless if people need.

I can't speak to Trigger, as they've changed a lot since I last looked. It doesn't look like they do durable execution, workflows, steps, or events — it looks like they're an alternative to Lambda + SQS for TS only, so very different — more for your simple "run one thing in the background", from what I can gather. Take this with a grain of salt, though!

We'll roll out a change that releases source as GPL after 3-4 years next week, actually. I do appreciate these comments and points.

There are similarities with "durable workflows" but, honestly, a completely different approach. Lots of respect for them.

A few critical things:

* Inngest is primarily event driven. You send an event, we run one or more functions.

* Events give you lots of benefits: batching, rate limiting, replay, archiving, fan-out, etc.

* You also get a powerful event-based API in functions: `step.waitForEvent`. This lets you do a lot of things: human in the loop flows, coordination — and you don't have to learn complex APIs, worry about state, can handle timeouts easily.

* And events also let you connect things like webhooks, CDC, external systems to functions with basically zero overhead.

* Because of this, you can pause individual functions, then redrive events through specific functions - as events are stored for you in an OLAP event store for your workspace.

Fundamentally, in terms of DX:

* You don't have to register individual activities and workflows. Steps are lambdas. It's easy to work with

* Every step (activity) has an ID, which means versioning, replay, determinism is easier to reason about and see in our model.

* We also run on servers as well as serverless. It's actually quite nice bringing state and retries to serverless functions - they're good for (some) bursty workloads

* We also embed a bunch of flow control into the system for you.

Overall, both replace queueing systems. I think that's a good thing: you shouldn't really have to think about the specifics of your underlying infra when you're writing application code.

Our launch week starts on Monday. There's something coming, with a full roadmap for differing DBs, multi-node setups, and metrics :)

Thanks! There are a few things at play. High level, it's important to note we provide infra for you — so our multi-tenancy supports many tenants for every user.

In general, fairness means distributing work evenly amongst all accounts. This largely means partitioned queues. Firstly, every functions have their own queues. We have queues of queues: queues of functions available. And then we have queues of accounts. And so on. It's like nesting dolls all the way down.

There are lots of really fine details to get right: continuations, step parallelism, `connect()` with long running workers all mess with fairness, as do batching, debounce, throttling.

We wrote about it in some detail here: https://www.inngest.com/blog/building-the-inngest-queue-pt-i.... We'll probably do some deeper dives on this next year, too!

Inngest | San Francisco (preferred) + Remote

https://www.inngest.com is a modern queueing/durable execution platform that allows all developers to ship fast, reliable code without managing infra, queues, or state. Our users write step functions in their existing codebase, and we handle the backend infra, queueing, scaling, concurrency, throttling, rate limiting, batching, o11y, and tracing for you.

We're beginning the hiring process for:

* Infrastructure engineer: an infrastructure engineer to help build and deploy our queueing system, state store, etc. on bare metal, then eventually our own hardware.

You can see the jobs here: https://jobs.ashbyhq.com/inngest.

I wrote this last month to get ahead, and the hiring process kicks off tomorrow. HN is great!

Inngest | San Francisco + Remote

https://www.inngest.com is a modern queueing/durable execution platform that allows all developers to ship fast, reliable code without managing infra, queues, or state. Our users write step functions in their existing codebase, and we handle the backend infra, queueing, scaling, concurrency, throttling, rate limiting, batching, o11y, and tracing for you.

We're beginning the hiring process for:

* Mid-Sr Frontend engineer: responsible for building out our design system, real-time metrics, and o11y stack on our cloud.

* Infrastructure engineer: an infrastructure engineer to help build and deploy our queueing system, state store, etc. on bare metal, then eventually our own hardware.

Jobs will soon go up on our website, but I want to get ahead of it in this thread. HN has great talent!

For more information email me: tony [at] inngest.com.

Ah, yes, fair. Someone (and I don't know who) mentioned our company so I did jump in... kind of fair, too. I'l leave this thread :)

We're source available, and a helm chart will be coming soon. We're actually doing the last of any queue migrations now.

One of our key aspects is reliability. We were apprehensive of officially supporting self hosting with awkward queue and state store migrations until you could "Set it and forget it". Otherwise, you're almost certainly going to be many versions behind with a very tedious upgrade path.

So, if you're a cowboy, totally self hostable. If you're not (which makes sense — you're using durable execution), check back in a short amount of time :)

Chiming in as the founder of https://www.inngest.com. It looks like Hatchet is trying to catch up with us, though some immediate differences:

* Inngest is fully event driven, with replays, fan-outs, `step.waitForEvent` to automatically pause and resume durable functions when specific events are received, declarative cancellation based off of events, etc.

* We have real-time metrics, tracing, etc. out of the box in our UI

* Out of the box support for TS, Python, Golang, Java. We're also interchangeable with zero-downtime language and cloud migrations

* I don't know Hatchet's local dev story, but it's a one-liner for us

* Batching, to turn eg. 100 events into a single execution

* Concurrency, throttling, rate limiting, and debouncing, built in and operate at a function level

* Support for your own multi-tenancy keys, allowing you to create queues and set concurrency limits for your own concurrency

* Works serverless, servers, or anywhere

* And, specifically, it's all procedural and doesn't have to be a DAG.

We've also invested heavily in flow control — the aspects of batching, concurrency, custom multi-tenancy controls, etc. are all things that you have to layer over other systems.

I expect because we've been around for a couple of years that newer folks like Hatchet end up trying to replicate some of what we've done, though building this takes quite some time. Either way, happy to see our API and approach start to spread :)

Disclaimer: I work for Inngest (https://www.inngest.com), which works in the same area and released 2 years ago.

The restate API is extremely similar to ours, and because of the similarities both Restate and Inngest should work on Bun, Deno, or any runtime/cloud. We most definitely do, and have users in production on all TS runtimes in every cloud (GCP, Azure, AWS, Vercel, Netlify, Fly, Render, Railway, Cloudflare, etc).

MLIR is cool and has an exciting future for sure.

Something like Inngest's multi-tenancy aware flow control should be table stakes for most complex products now: https://www.inngest.com/docs/guides/flow-control.

Huge disclaimer here: I'm one of the founders. You should most definitely be able to set concurrency levels, throttling, rate limiting, etc. per your own tenant, in code, without having to mess around with creating independent queues or streams for users, and without managing state. We let you do that.

I know Theo. He’s a good person who wants to educate folks, and make things simpler.

There are problems with education: you often have to make things contrived to show problems as fast as possible, and it’s hard to convey all of the nuance. Theo, and others, definitely try to strike that balance and I think it’s fair to say that this is because of how the front end world works rather than because of personalities.

Hevy gives you all of this for free, with routines, RIR, rest timers, supersets, 1rm, session, and set volume all easily visible.

No, not given the people who created Redis, built distribution, made it a standard didn’t get paid. Open source isn’t about letting someone else gain from your work. It’s about openness. That’s why it’s of course in AWS’ benefit to support a fork. They claim to have helped the project therefore should be trusted going forward, despite latching onto it after the work was done to gain adoption. That’s fairly controlling and manipulative.

Yeah, they probably could/should.

It'd take a lot to get developer adoption and buy in to a separate product that AWS builds themselves, so they adopted Redis. Easy money. It's easier to piggyback on something that won while making lots of money from it and say "well, I helped..." if things chanbge. Then, they chastise the creators as bad people once the gravy train stops.

AWS benefited from hosted redis before contributing. It wasn't adopted out of benevolence. They're still doing it with Memcached, for what its worth.

Fun times ahead!

I talked to the Cloudflare team at Clerk's ecosystem hackathon last year, showed them Inngest, and they were really enthusiastic about our model. They said something like "we've been thinking about this for some time but couldn't figure it out".

APIs are only part of it. "Flow control" — concurrency, waitForEvent, sleeps, batching, debounce, etc is key. Observability is key. People emulating our APIs is always going to happen, and it's no big deal. The only sad part is that they don't call out any inspiration; we literally asked them to work with us for this with R2 last year.

It's always good to get validation, and I'm glad our API makes sense to folks. The feedback we get from developers is always extremely good.

Disclaimer: I'm a founder of Inngest.

I suppose it depends on the API. Some languages require grabbing a handle and calling open. Either way, theory is the same!

This seems similar to replicating substructural type systems like linear or affine types via interfaces.

I can't remember who gave this talk, but a prime example is a `File` type. A `File` type shouldn't have a Read() method until the file itself has opened. And calling `Close()` on the File should prevent further reads. Substructural typing - and this pattern - allows you to refine types based off of the type's instance state.

There's a ton possible here but I haven't really kept up to date with type systems in the last 5 years. Stuff like this has probably advanced a ton!

Isn't that what integration tests are for? I really don't understand why we'd use a 3rd party system that's not part of a CI to test an API.

That's... what code is for? Why are developers sharing "requests" if we all need to build an API client?

I hear you, and there's relatively little literature on what making MCAS more powerful means.

You might assume that this was after the first test flight (also 2016), and that the lead engineer on the system decided to increase the lift MCAS applies after a real-world test. Would they run that by the CEO? Surely not. Was the MCAS system already approved before Dennis? Yea. Would Dennis take a massive risk by cancelling a 6 year project as he became CEO? Definitely. He's between a rock and a hard place. I can't see that he's at fault.

The people who are at fault are the ones who green lit. IIRC, that was an MBA CEO, obviously in tandem with an engineering team who came up with the idea.

He was CEO from 2015 onwards. The MAX' first flight was 2016. It's safe to say that Dennis didn't have a say in greenlighting the MAX program, unless he was such an impactful CEO that he could greenlight MAX and get the plane built in a year, in which — well, good job? It turns out that during the max program, Dennis was managing Boeing's security division.

Pointing to Dennis as a failure of an "engineering CEO" because of the MAX incident isn't accurate.

We support TS, Python, Golang, and Java/Kotlin with official SDKs, and our SDK spec is open, so yes — any server can handle it :)

I built https://www.inngest.com specifically because of healthcare flows. You should check it out, with the obvious disclaimer that I'm biased. Here's what you need:

1. Functions which allow you to declaratively sleep until a specific time, automatically rescheduling jobs (https://www.inngest.com/docs/reference/functions/step-sleep-...).

2. Declarative cancellation, which allows you to cancel jobs if the user reschedules their appointment automatically (https://www.inngest.com/docs/guides/cancel-running-functions).

3. General reliability and API access.

Inngest does that for you, but again — disclaimer, I made it and am biased.