So many software homepages use that tailwind template, or a variety of it. As soon as I see it, it suggests to me a poor quality/rushed product.
Apache Burr: Build reliable AI agents and applications
111–120 of 125 posts
Re: Apache Burr: Build reliable AI agents and applications
#112Earlier quoted context omitted.
Burr is named after Aaron Burr, founding father, third VP of the United States, and murderer/arch-nemesis of Alexander Hamilton. What's the connection with Hamilton? This is DAGWorks' second open-source library release after the Hamilton library We imagine a world in which Burr and Hamilton lived in harmony and saw through their differences to better the union. We originally built Burr as a harness to handle state be…
Right it was a bit of a joke. Originally stefan and I presented frameworks when we were at stitch fix -- stefan called his "hamilton" and I called mine "burr". His was better for the use-case. But then we wanted to build something for state machines as opposed to DAGs, so we called it Burr. I wanted the git tagline to be "make your agents go burr..."
Re: Apache Burr: Build reliable AI agents and applications
#113A builder pattern and decorators. Yes, Python has decorators, but they're best used as "filters" that apply to functions or methods. Cache this, serialize the output of this function always, prepare this function to be used as a tool by an agentic harness. Not registration, not flow control. You may disagree but someone has to say it; FastAPI influenced the modern use of decorators far too much in the wrong direction…
Re: Apache Burr: Build reliable AI agents and applications
#114Earlier quoted context omitted.
Pi is a nice multi-agent wrapper. I use it to wrap my OpenAI max plan calls and my API calls. It takes care of some of the agent plumbing - still need sandbox, orchestrator, compounding, context, evals, etc but it's a nice component.
Any particular plugins you'd recommend? For orchestration I gave pi-subagents a try, and didn't care for it, ended up with hung agents sticking around forever and I wasn't even doing anything terribly fancy. Claude's subagent control is annoying and clumsy, but it works.
Re: Apache Burr: Build reliable AI agents and applications
#115I found the Spec Driven Development approach works nicely for me, and I've been using it since Feb 2026 for all my mid+ size projects. I started with the GSD plugin, but it soon became too heavy, so I implemented my own lightweight SDD-based workflow for Claude. A friend of mine ported it to gemini-cli, and that version was added to Google's approved third-party frameworks for internal usage. The idea is to decompose feature implementation into multiple steps, task implementation into multiple subtasks, and be able to clear the context after every task/implementation.
Repo: https://github.com/sermakarevich/sddw
Slides: https://docs.google.com/presentation/d/1SjKXF7hkoqyiN9-3tBGY...
When SDD was not enough, I started playing with scaling a single AI worker to multiple, and then got to an agent swarm. Built on top of a centralized Beads database, claude -p headless execution, a UI, a custom ask_user MCP, and Telegram integrations, fleet (the app name) lets me add many tasks in advance, control the number of workers executing them, and use any kind of coder/model. It works nicely with the SDDW implementation phase. It shines when you keep creating tasks, define dependencies between them, and give clear descriptions. For personal projects I can queue up 70 tasks for an overnight run, set the number of workers to 1 to not be blocked by usage limits, and let it roll.
Repo: https://github.com/sermakarevich/fleet
Slides: https://docs.google.com/presentation/d/1O_pXyKdtpRG2ORD1xw7s...
Since Fable 5 appeared, I've been changing the way I work with fleet. Instead of adding tasks/descriptions/dependencies to fleet myself, I talk to Fable: specify the goal, ensure understanding, and let Fable 5 add tasks to fleet. Fable is expensive, but in this setup it doesn't code — it just investigates, designs, decomposes, and creates tasks. Workers use the cheaper Sonnet 4.6 model.
Reliability comes with task implementation decomposition into multiple steps, feature decomposition into many smaller and simpler subtasks, having better description, clean and focused context.
Re: Apache Burr: Build reliable AI agents and applications
#116Earlier quoted context omitted.
> If a developer wanted to change X, would these keywords help them find this file? I think the best way to generate these is with a sub-agent. Tell it to try and solve a problem that involves editing this file, and see what it starts grepping for. This ties in with this idea that the tools and designs should be what comes naturally to the LLM, i.e. what it's already been trained on. And the most straightforward way…
My solution has a natural self improvement loop. Once you have finished a task, you just ask the agent "If you had more information, how would you have finished the task sooner and/or better?" This was how I came about the rust blast radius brain. I need to modify OpenAI's Codex agent to support slash commands that can help humans better guide agents, and I needed a solution with the least impact. They don't accept c…
Are you running it with official or custom models? I've been trying to get custom models working in Codex and haven't been able to figure it out. (A lot of providers support Responses API, but they don't actually work with Codex.)
Re: Apache Burr: Build reliable AI agents and applications
#117Re: Apache Burr: Build reliable AI agents and applications
#118So many software homepages use that tailwind template, or a variety of it. As soon as I see it, it suggests to me a poor quality/rushed product.
I agree. As with Bootstrap, it was fine in the beginning but at some point turned sour - strictly speaking about Look & Feel.
If that’s all the effort you are going through to make your brochure site, I can only assume the same care was given to the actual product.
Re: Apache Burr: Build reliable AI agents and applications
#119Re: Apache Burr: Build reliable AI agents and applications
#120Earlier quoted context omitted.
My solution has a natural self improvement loop. Once you have finished a task, you just ask the agent "If you had more information, how would you have finished the task sooner and/or better?" This was how I came about the rust blast radius brain. I need to modify OpenAI's Codex agent to support slash commands that can help humans better guide agents, and I needed a solution with the least impact. They don't accept c…
Nice, tell me more about your Codex fork. Are you running it with official or custom models? I've been trying to get custom models working in Codex and haven't been able to figure it out. (A lot of providers support Responses API, but they don't actually work with Codex.)
I created a new brain that helped me find the answer for what you described:
> Codex does not just need a /v1/responses endpoint. It needs an OpenAI Responses-compatible agent surface. Many providers implement enough Responses API for text streaming, but not enough for Codex’s tool-call loop and event mapping.
I can understand why they might have done this for performance and/or lock-in and/or AI thinking reasons.
I don't think I will create a translation layer, as that would be a sync nightmare, so based on what I found and what you said, it doesn't look like you can use other providers unless you introduce a proxy layer to translate things.
I should also note, even if you have the translation layer, you might end up breaking harness capabilities.
I am going to update
https://github.com/gitsense/smart-codex
to include the `codex-rust-navigation` brain that you can use to chat with AI about. And you will probably want to use it since `gpt-5.5` estimated that 25 - 50 files did not have to be read:
> Roughly 300-500 files avoided, with a defensible lower bound around 25-50 files.
This brain is designed specifically for rust files so you will need to use code-intent if you want to ask more documention/config questions.