Why not build the next cloudflare then, I'm sure it is appreciated by HN folks.

Can your team of agents figure out why the extremely basic homepage does a stutter step on a $7000 Macbook Pro: or are they taking off Thanksgiving?

https://imgur.com/a/WZG9VLm

Can I get this in an ant-farm mode where I can see them doddle around a cube-farm office?

Interesting approach, but I mean more in the sense of a multi-agent sandbox than workflow automation. Your project feels like wrapping a bunch of LLMs into "agents" with fixed cadences, it is a neat product idea, even if it mostly ends up orchestrating API calls and cron jobs.

The thing I’m curious about is the emergent behavior, letting multiple LLMs interact freely in a simulated organization to see how coordination, bottlenecks, and miscommunication naturally arise.

Cool project regardless!

How hard would it be to run a simulator with multiple LLMs. Say, one as the boss and a few as employees. Just let them talk, coordinate, and "work"? Could be the fastest way to test what actually happens when you try to automate management.

Some of these causes of death (“dead in the streets”, “scalded in a brewer’s mash”) remind me of The Gashlycrumb Tinies [0]

[0] https://en.wikipedia.org/wiki/The_Gashlycrumb_Tinies

Haha, I like to joke that we were on track for the singularity in 2024, but it stalled because the research time gap between "profitable" and "recursive self-improvement" was just a bit too long that we're now stranded on the transformer model for the next two decades until every last cent has been extracted from it.

Since people are a bit WTF is this, here's a point to combinators.

A combinator is a function that doesn't mutate global state and doesn't close over variables. It's the base case in software. Pass it the same argument, get the same result, doesn't change anything about the rest of the system.

If you combine some of these combinators, you get another combinator - because when you put pure functions together, what you get is a pure function.

These are also the functions that are easy to write in assembly. Or C. Because the don't do very much. So if you write S and K in x64, and then compile common lisp to combinators written in terms of combinators written in terms of S and K, what you've got is common lisp running on those two hand written assembly functions.

That's not a great idea for performance, but if you go with a less spartan set of maybe a few hundred of the most commonly occurring patterns inlined into each other and given names, you've got a viable way "machine" to compile functional programs into.

This looks a bit like a forth that fears mutation. Or a bytecode vm. Or a CPU, where the combinators are called "instructions".

So what combinators are, broadly, is an expression of applied computer science with implementation details ignored as much as possible. That's the sense in which it's simpler than the lambda calculus.

Equally, if you implement the lambda calculus on a handful of combinators, then implement lisp on the lambda calculus, then write stuff in that lisp, you've really cut down how much machine specific work needs to be done at the bottom of the stack.

holy shit.

there’s an interesting (but not necessarily causual in either direction) link between chess and depression https://www.chess.com/blog/AstroTheoretical_Physics/chess-pl...

either how, RIP