2 months ago
Not necessarily the most capable one.
I'm more interested in projects that introduced a genuinely interesting idea or solved a problem in a different way.
Could be open source, research, infrastructure, orchestration, memory systems, agent frameworks, or anything else related to autonomous systems.
What stood out to you?
i work for a company that focuses on unified context layers, all in one native platform, etc, and all of the marketing/sales convos are all about agents. no one seems to really care or think much of the data organization underneath it
Exactly. That’s the part I think gets under-discussed.
Everyone wants to talk about “agents”, but once you try to make them useful in real workflows, the value starts moving down into the infrastructure layer: context, data organization, connectors, permissions, auth, tools, logs, recovery, and making sure the agent can actually access the right thing at the right time.
The agent is the visible part, but the system underneath is what decides whether it works reliably or just looks good in a demo.
Changing my perspective on what AI agents should be has opened up my view of them. I'm starting to view them more as employees rather than agents. By fixing my perspective to that, it has forced me to set them up differently, especially for clients. Now I start with the question "What do I want this new hire to do for me or the client?". Viewing the agent as a remote worker changes everything: how do I want them to communicate with me? what can I tell them about the company or me that will help them understand their job? what processes and files can I give them to start them out on learning their "hired" tasks.
In one case, the agent, who was onboarded with a company email, handbook and some spreadsheets, can now responds to the boss with bid spreadsheets, asking the necessary questions to clarify. It even reports its hours each week to payroll. In another case, the ai agent who was hired to create and improve a website, was given a goal and told not to expect anymore input, but to make the website the best in the areas. It works on the website each day and evaluates input in order to know what to work on, e.g. topics that have more traffic, SEO improvements if there is a lack of traffic, responding to email input from visitors.
If we are going to differentiate between AI agents and existing semi-autonomous tools like CODEX, Claude Code, etc., then how should these AI agents be used differently? I'm going in the direction that for them to be used differently (assuming with greater benefit), then I need to treat and view them differently, i.e. like I would an enthusiastic, quick learning person.
I’ve been living in the infrastructure side of this exact space for the last year. (Full disclosure: I'm building an open-source project called PipesHub).
To your point about solving things differently—we noticed everyone is obsessed with building better reasoning frameworks and agent loops right now. But we found that even the smartest agent completely falls apart in production for a really basic reason: it can't easily access or make sense of messy, siloed company data.
We got so frustrated building custom data pipelines just to get an agent to answer a basic question, so we decided to build a dedicated context and retrieval layer that just sits underneath whatever framework you're using.
The architectural shift for us was ditching the "just use a vector DB and dump chunks into the prompt" approach. We wired a Knowledge Graph up alongside the vector search. This way, the agent actually drives its own retrieval—if it needs a hard metric or relationship, it hits the graph. If it needs broad context, it pulls the document.
The whole goal was getting time-to-first-value as close to zero as possible. We open-sourced the core engine so devs can just grab the repo and spin up the architecture locally to test it out.
If you folks are digging into the memory and data-infrastructure side of autonomous systems, I’d love for you to poke around the repo and let me know if this approach to context actually makes sense to you.
For me, the most interesting direction lately is agent infrastructure rather than the agent itself.
Planning and memory are cool, but the real bottleneck seems to be the connector layer: OAuth, tokens, API scopes, local secrets, safe execution, retries, and making sure an agent can actually use real services without leaking credentials or breaking workflows.
Less flashy than a new framework, but probably much closer to what makes agents useful in practice.