But sometimes people just need something to do, or something fun to play with, and “the next guy” rarely matters that much… so who cares that you’ve saddled them with the result of your paid playtime?

Where I'm starting to question this is maintainability. When I come up with a new technique or way of doing something in my new agent, how can I update an older agent. Do I want to update the older agent?

But, I get what you're talking about w.r.t. building for the exact problem at hand. For example, I'm guessing that Apache Burr has support for a plugin-able vector RAG system (or at least it will if it doesn't now). That's great, but I want my RAG system to add documents to the context and keep them as part of an updated system prompt with some very specific tweaks that happen as part of that process. This is a bespoke way of working with an existing concept (RAG) that doesn't lend itself to using any specific framework.

In my use-case, bespoke is the way to go. But then I'm still stuck with having to make engineering choices for updating older agents. So, I see your point.

Don't need to get it all from one vendor, but that feels to me like the toolkit and for most use cases I'd argue: - Don't limit yourself to a single model provider (anthropic, openai, etc) - Own your context - Own your compounding

And just like when people were trying to figure out which sorting algorithm made the most sense, we are all just trying to figure out which prompt algorithms with which models lead to good results.

4 months of mostly spinning their wheels later they launched a really lackluster OC product that's effectively DOA.

> Context management so the right agents have the right context for the right sessions at the right time

I'm going to do a show HN tomorrow that explains how you can give your agents years of experience. The basic idea is, you would commit in your repo or download manifests (JSON files) that can be converted to "Brains" (SQLite databases). Each brain can have its own properties.

For example, I provide a "code intent" analyzer (instructions for AI) that says when analyzing a file, extract this metadata. For the code intent analyzer, I have the AI extract a single sentence purpose for the file. So if you execute:

gsc rg cache --db code-intent --fields purpose

you get all matches for 'cache' plus the matching file's purpose like "Modify file to update caching strategy". This is how the agent can tell if the file is talking about cache vs. whether this file is what you should change if you want to update the caching strategy.

So for what you described, you can have a brain for different stages of a task. It can be as simple as, in the planning stage, make sure you do this if you need to touch this file.

I am working on a rust-blast-radius brain that uses `syn` + AI generated metadata to help you understand "what if I changed this file, what would be affected". With the rust-blast-radius brain, the AI can summarize the types of files that will be affected without having to open the file based on what has been changed or discussed.

So you can have a rule like, if I make changes to a Rust file, make sure to do a blast radius analysis so we don't forget to consider something.

Does this align with what you are looking for?

When building an agentic workflow there are enough primitives that rewriting them from scratch every time makes zero sense.

What is a tool? How does the LLM understand the tool? Formatting a native function into a serializable input/output pattern makes sense to generalize and that does not need to exist repeated in everyones application code.

We use libraries to interact with the APIs themselves; nobody would say writing a spec-compliant API client was poor practice. Agentic harnesses are just one layer above: I need to call the API and I need to do it with certain expected conventions.

I’ve been playing with this stack and left wondering if Strands provides any secret sauce with Agent Core. So far it doesn’t feel that way and sometimes they even feel at odds with each other.

https://tcl.apache.org/rivet/

https://burr.apache.org/docs/examples/agents/

https://pypi.org/project/burr/

One, obviously yes OC contains a lot more than a harness, but my point was that it was too much for their use case and constrained their choices, not enabled them, and that choosing the right layer of abstraction is important.

There's good indirection/abstraction and there's ones that do not serve your use case, eg what was obviously day one regarding Langchain.

Another thing I've been thinking is how, most parts of a file are not relevant to the whole system.

Like there are parts where they intersect, and those seem to be the most important ones for capturing the big picture. You wanna be able to see the entire "skeleton".

So I thought the summary maybe shouldn't be English but it should be a subset of the code — the subset that's relevant to the rest of the program.

`grep import` gets you 90% of the way there.

so far I'm seeing: GradientText, Animated button, EyebrowPill, Aurora background, MockIDE, LogoRow, SlippyWords, StatCounter, CommunityBadge

also: "No DSL, no YAML — just Python functions and decorators."

'It's not X, its Y' but with an added em dash is crazy work.

It might sounded that I’m against the move, but I’m just curious as what apache found in the platform to get incubated

https://github.com/gitsense/chat/blob/main/base-state/analyz...

In your chat with AI, include the above file and let it know what your requirements are and I can create the analyzer and include it.

You can also think of my tool as data prepping tool. So if you have a clear prompt the AI can review the file during analysis and remove all unnecessary code so the extracted metadata will the stripped text which you can use search against.