the_mitsuhiko

I don’t think this is a technical problem but a social problem. I think the audience defines itself by being the antithesis to Twitter instead of being a well balanced one.

I was pretty optimistic in the beginning but Bluesky doesn’t have organic growth and those who hang out there, are the core audience that wants to be there because of what the platform represents. But that also means rejection of a lot of things such AI.

So far my experience is that unless you subscribe to the general narrative of the platform, the discover algorithm punishes you with directing the mob your way.

I had two of my Bluesky posts on AI being attacked by all kinds of random people which in turn has also lead to some of those folks sending me emails and dragging some of my lobster and hackernews comments into online discourse. A not particularly enjoyable experience.

I’m sure one can have that same experience elsewhere, but really it’s Bluesky where I experienced this on a new level personally.

> It's implantation should be abstracted away from the main agent loop. Whether the tool call is deterministic, has human input, etc, is meaningless outside of the main tool contract (i.e Params in Params out, SLA, etc)

Up to a point. You're obviously right in principle, but if that task itself has the ability to call into "adjacent" tools then the behavior changes quite a bit. You can see this a bit with how the Oracle in Amp surfaces itself to the user. The oracle as sub-agent has access to the same tools as the main agent, and the state changes (rare!) that it performs are visible to itself as well as the main agent. The tools that it invokes are displayed similarly to the main agent loop, but they are visualized as calls within the tool.

It's not controversial to say that submissions are being moderated, that's how this (and many other) sites work. I haven't made any claims about how often it happens, or how it relates to second-chance moderation.

What I'm pointing out is just that moderation isn't the same at different times of the day and that this sometimes can explain what content you see during EU and US waking hours. If you're active during EU daytime hours and US morning hours, you can see the pattern yourself. Tools like hnrankings [1] make it easy to watch how many top-10 stories fall off the front page at different times of day over a few days.

[1]: https://hnrankings.info/

I’m referring to the actual moderators of this website removing posts from the front page.

> EU waking hours have comments that seem disconnected from genAI. And, while the US hours show a lot of resistance, it's more fear than a feeling that the tools are worthless.

I don't think it's because the audience is different but because the moderators are asleep when Europeans are up. There are certain topics which don't really survive on the frontpage when moderators are active.

They are using RAG. Grep is also just RAG. The better question is why they don’t use a vector database and honestly the answer is that these things are incredibly hard to keep in sync. And if they are not perfectly in sync, the utility drops quickly.

> does anybody know why there’s no agentic tools that use tree-sitter to navigate code?

I would guess the biggest reason is that there is no RL happening on the base models with tree-sitter as tool. But there is a lot of RL with bash and so it knows how to grep. I did experiment with giving tree sitter and ast-grep to agents and my experience the results are mixed.

> If explicit caching is better, does that mean the agent is just forgetting stuff unless we manually save its notes?

Caching is unrelated to memory, it's about how to not do the same work over and over again due to the distributed nature of state. I wrote a post that goes into detail from first principles here with my current thoughts on that topic [1].

> Are these things really that forgetful?

No, not really. They can get side-tracked which is why most agents do a form of reinforcement in-context.

> Why is there a virtual file system?

So that you don't have dead-end tools. If a tool creates or manipulates state (which we represent on a virtual file system), another tool needs to be able to pick up the work.

> Why can't the agent just know where the data is?

And where would that data be?

[1]: https://lucumr.pocoo.org/2025/11/22/llm-apis/

Author here. I’m with you on the abstractions part. I dumped a lot of my though so this into a follow up post: https://lucumr.pocoo.org/2025/11/22/llm-apis/

I think pgqueuer is like pgmq which I used a lot. pgmq is just the queue part, absurd does the state storage. I wrote some more about why it exists here: https://lucumr.pocoo.org/2025/11/3/absurd-workflows/

I think this is great. We should see more simple solution to this problem.

I recently started doing something very similar on Postgres [1] and I'm greatly enjoying using it. I think the total solution I ended up with is under 3000 lines of code for both the SQL and the TypeScript SDK combined, and it's much easier to use and to operate than many of the solutions on the market today.

[1]: https://github.com/earendil-works/absurd

> * Contrary to APIs, they can change their interface whenever they want and with little consequences.

I already made this argument before, but that's not entirely right. I understand that this is how everybody is doing it right now, but that in itself cause issues for more advanced harnesses. I have one that exposes MCP tools as function calls in code, and it encourages the agent to materialize composed MCP calls into scripts on the file system.

If the MCP server decides to change the tools, those scripts break. That is is also similar issue for stuff like Vercel is advocating for [1].

[1]: https://vercel.com/blog/generate-static-ai-sdk-tools-from-mc...

> Don't you have a post about writing Python instead of using MCP?

Yes, and that works really well. I also tried various attempts of letting agents to write code that exposes MCP tool calls via an in-language API. But it's just really, really hard to work with because MCP tools are generally not in the training set, but normal APIs are.

I don't find that to help much at all, particularly because some tools really only make sense with a bunch of other tools and then your context is already polluted. It's surprisingly hard to do this right, unless you have a single tool MCP (eg: a code/eval based tool, or an inference based tool).

The question that is at the core is “police can wire tap calls but they cannot wire tap chats. Should this change?” The details are not all that important to people.

> How does society resolve this kind of abuse of the democratic process? It is a dynamic that is repeated in many areas.

A lot of society wants this. A lot of parents are asking for this.

And Europeans don't it because quite frankly, we're not really doing anything particularly impressive with AI sadly.

> idempotency (absurd does this via steps - but would be better handled with the APIs themselves being idempotent, then not using steps

That is very hard to do with agents which are just all probabilistic. However if you do have an API that is either idempotent / uses idempotency keys you can derive an idempotency key from the task: const idempotencyKey = `${ctx.taskID}:payment`;

That said: many APIs that support the idempotency-key header only support replays of an hour to 24 hours, so for long running workflows you need to capture the state output anyways.

It's quite funny in a way for me because even back in the Cadence days I thought it was the hottest shit ever, but it was just too complex to run for a small company and cadence was not the first (SWF and others came before). It felt like unless you had really large workflows you would ignore these systems entirely. And now, due to the problems that agents pose, we're all in need of that.

I'm happy it's slowly moving towards mass appeal, but I hope we find some simple solutions like Absurd too.

> Could you provide some more specifics as to why DBOS isn’t “ready for prime time”? Would love to know what you think is missing!

Some time in September I was on a call with Qian Li and Peter Kraft and gave them direct feedback. The initial reason this call happened was related to a complaint of mine [1] about excessive dependencies on the Python client which was partially remedied [2] but I felt it should be possible to offload complexity away from the clients even further. My main experiments were pretty frustrating when I tried it originally because everything in the client is global state (you attach to the DBOS object) which did not work for how I was setting up my app. I also ran into challenges with passing through async and I found the step based retry not to work for me.

(There are also some other oddities in the Python client in particular: why does the client need to know about Flask?)

In the end, I just felt it was a bit too early and I did not want to fight that part of the infrastructure too much. I'm sure it will get there, and I'm sure it has happy users. I was just not one of them.

[1]: https://x.com/mitsuhiko/status/1958504241032511786

[2]: https://x.com/qianl_cs/status/1971242911888281608

> I took a brief look at your docs. What would you say is the main difference of yours vs some of the other options? Just the simplicity of it being a single sql file and a sdk wrapper? Sorry if the docs answer this already - trying to take a quick look between work.

It's really just trying to be as simple as possible. I was motivated by trying to just do the most simple thing I could come up with after I did not really find the other solutions to be something I wanted to build on.

I'm sure they are great, but I want to leave the window open to having people self host what we are building / enable us to deploy a cellular architecture later and thus I want to stick to a manageable number of services until until I can no longer. Postgres is a known quantity in my stack and the only postgres only solution was DBOS which unfortunately did not look ready for prime time yet when I tried it. That said, I noticed that DBOS is making quite some progress so I'm somewhat confident that it will eventually get there.

That's a completely unrelated issue. Once someone sent you a link to a tweet, you could read it.

Publishing frontend source maps is not uncommon and quite often done intentionally.

Oh interesting, maybe this makes for a better example then. If it has DBOS and Temporal it must be exposing some way to drive the loop. I'll investigate.

> short answer--maybe not that _hard_, but it adds a lot of complexity to manage when you're trying to offer real-time search. most vector DB solutions offer this ootb. This post is meant to just point out the tradeoffs with pgvector (that most posts seem to skip over)

Question is if that tradeoff is more or less complexity than maintaining a whole separate vector store.

> Okay very clear! I was saying that because your post example is just a kind of basic "tool use" example which is already implemented by MCP/OpenAI tool use, but obviously I guess your code can be suited to more complex scenarios

That's mostly just because I found that to be the easiest way to use any existing AI API to work. There are things like vercel's AI SDK which internally runs the agentic loop in generateText, but then there is no way to checkpoint that.

> I was just wondering, how does it work? I was more expecting a generator with a `yield` statement to run "long-running tasks" in the background... otherwise is the node runtime keeping the thread running with the await? doesn't this "pile up"?

When you `awaitEvent` or `sleepUntil`/`sleepFor` it sets a wake point or sets a re-schedule on the database. Then it raises `SuspendTask` and ends the execution of the task temporarily until it's rescheduled.

As for your IOT case: yes, you should be able to do that.

It's part of the problem. Pretty sure though even rustc at this point needs more than 3GB of addressable memory.

There are not that many agent frameworks around at the moment. If you want to be provider independent you most likely either use pydantic AI or the vercel AI SDK would be my guess. Neither one have built-in solution for durable execution so you end up driving the loop yourself. So it's not that I don't use these SDKs, it's just that I need to drive the loop myself.

I'm sure with time DBOS will be great, I just did not have a lot of success with it when I tried it. It's quite complex, the quality of the SDKs was not overly amazing (when I initially used it, it had a ton of dependencies in it) and it just felt early.