Veselin Dimitrov

@sarahwooders i guess it was a transitional problem/solution for people that were used with slash commands now I use the / if the harness supports it mainly to check if a skill exist and is visible

I never really understood the `/{skill-name}` thing since I just ask my agent to call skills... but finally added it anyway github.com/letta-ai/letta…

@ProductHunt @gustaf just open-sourced the expertise layer for your coding agents github.com/berserkdisrupt…

it's less than two days until YC day where one or more products will be selected by @gustaf for a YC interview What are you shipping? Drop it in the replies 👇

now if think deeper, actually i’ve seen the benefit of their simple memory system without realising recently when i doing similar research to yours - compared if to extend pi from @badlogicgames or go with langchain’s deepagents - it knew exactly why i am researching it and cross-referenced it with very meaningful memories from the overall “project” scope so i guess it depends on how you use those features

Anyone found this style of forced connection and inferred insights actually helpful? I've found it lands ~30% of the time. But overall gives me less faith in Claude's second order reasoning.

I get a flavour of well-intentioned but irrelevant "helpful memory" connections often in Claude. This morning researching KiloClaw vs self-hosted openclaw, Claude injects an unrelated memory, tries to square the circle. Memory features still in infancy? Hard to teach relevance?

@Mappletons i’ve rarely seen random memories polluting the main scope of what i am doing, but that’s also the reason why i use their “projects” feature

relying only on relevance is the actual problem… somehow it matched your past memory to the current query, but even their internal monitoring mechanisms won’t be able to tell how exactly not that it didn’t work, its just that the memory in these harnesses is not there yet i still believe that deterministic approaches will be the solution to these non-deterministic knn techniques

@sarahwooders not sure, but I would also love to see a natural home for github.com/berserkdisrupt…

Is anyone building github for agents? Specifically: - API/SDK interface - make millions of repos no problem - fast

i still remember my reaction the first time i gave memgpt cli a try back in late 2024 it was absolutely mind-blowing

it’s not that they want to write docs, we both know that docs drift fast… what they really want is to: - stop repeating themselves (reconstruct intent each new session) - talk to an agent that is fluent in their context and recalls historical decisions - get consistent results that belong with their codebase (conventions) - trust the outcome (verification procedures) - keep only persistent context that cannot be recreated from reading the code - share the same experience with their team the packages approach is good but it doesn’t cover the full spectrum of context types

@vidimitrov but for the first time developers want to write docs. Because they became the manager of agents :)

agree on the "rigor", but "context is the new code" isn't quite right what @patrickdebois describes was always part of code creation - lived in our heads and scattered docs, just never captured its not new - we need the right taxonomy to define it and a way to materialise it reliably

@jeremyklar @ashwingop @t_blom you are right that in coding harnesses we have the knowledge available and it is the code but what we really need is the expertise - the way we use that knowledge in real world scenarios accuracy is not the only goal here… producing outcomes that belong is the real game here

AI Brain / Knowledge Layer architecture is suddenly everywhere . I've read a ton of great content on it— @t_blom even put out a YC RFS for it. After deploying live AI Brain systems across gaming studios, law firms, and consultancies, here's the pattern I keep seeing and what I've done that has worked: TL;DR — the knowledge layer is the part teams underbuild, and it's the part that decides whether the agent is accurate or just confidently wrong. Wrote it up below: (h/t @ashwingop and @akshay_pachaar whose content helped me refine a lot of this)

we just need a standard way to express how each repo is different… harnesses has to be minimalistic and adaptable so when you open a repo, that self-contains all of its context (not just the code) the harness should feel different, but in a good way - specific, grounded, custom

@richmondalake looks good, congrats on the launch 👏 what I missed while reading the benchmark results was a comparison to other existing solutions are you planning to integate the solution with existing coding harnesses and support other languages too?

Proud to announce the launch of Oracle AI Agent Memory Package. When I first started writing publicly about agent memory, most people thought the category was overrated. Vector stores were enough. Chat history tables were enough. Today that category ships as an Oracle product. A lot of companies talk about memory. Very few actually understand it. Even fewer ship it as something developers can use today. Oracle Agent Memory is live. A model- and framework-agnostic Python package, with one governed memory substrate on Oracle AI Database underneath it. Working, semantic, episodic, and procedural memory in one place, not four bolted-together services. 🖥️ pip install oracleagentmemory Here are three results from the work that went into this release. 1️⃣ On LongMemEval, the standard academic benchmark for long-context agent memory, Oracle AI Agent Memory scored 93.8% (469 of 500), with 100% on single-session assistant recall and 96% on temporal reasoning. 2️⃣ On token efficiency, an 80-turn scripted conversation showed Oracle AI Agent Memory holding context flat at around 1,300 tokens per request while a flat-history baseline grew linearly past 13,900. Roughly 9.5× fewer tokens per request by the final turn. 3️⃣ On answer quality, the same 80-turn conversation was judged turn-for-turn against the same flat-history baseline. The naive agent had the entire verbatim transcript in its context. It still lost, 48 turns to 13, with 19 ties. A retrieved context card focuses the model. A sprawling transcript dilutes attention across noise. We shipped framework-integration notebooks for every Python runtime that matters right now: LangChain's LangGraph, the Anthropic Claude Agent SDK, the OpenAI Agents SDK, WayFlow, and custom Python harnesses. All of them instantiate the same OracleAgentMemory client and read and write the same Oracle Database store. Migrations between frameworks no longer mean migrating memory. If you want to try it on your stack today: ⒈ pip install oracleagentmemory ⒉ Pick the framework you already use — LangGraph, Claude Agent SDK, OpenAI Agents SDK, WayFlow, or a custom Python harness ⒊ Open the matching notebook and replace the connection string with your own Oracle AI Database instance ‼️ Launch post, product page, and notebooks are all in the first comment below. A release like this is never one person's work. Genuine thanks to everyone on the team across @OracleDatabase who supported, contributed to, and shipped this package. We will keep listening to the developers on the frontline, the ones building AI agents that learn from new information, adapt to it, and keep doing both at production scale. They are the audience this substrate is built for, and the next iteration will be shaped by what they tell us. Memory Engineering is still a young discipline. The infrastructure behind it should not be.

true, but most importantly we have to find a way to capture and recall the decisions that shaped the software design so far we were the only consumers of these decisions, and it was fine to keep them only in our heads

Andrej Karpathy: "90% of what AI twitter tells you to learn will be dead in 6 months" Here are 10 things senior AI engineers stopped wasting time on: 1. AutoGen / AG2: moved to community maintenance, releases stalled. dead for production 2. CrewAI: demos well, breaks in production. engineers building real systems already moved off it 3. Autonomous agent pitches: the AutoGPT / BabyAGI wave is dead in product form. the industry settled on supervised, bounded, evaluated agents 4. Agent app stores / marketplaces: promised since 2023, zero enterprise traction 5. SWE-bench leaderboard chasing: researchers proved nearly every public benchmark can be gamed without solving the underlying task 6. Microsoft Semantic Kernel: unless you're locked into Microsoft enterprise stack, it's not where the ecosystem is heading 7. DSPy: philosophical merit, niche audience. not a general agent framework 8. Horizontal "build any agent" platforms: Google Agentspace, AWS Bedrock Agents, Copilot Studio. confusing, slow-shipping, the math still favors building yourself 9. Per-seat SaaS pricing for agent products: market moved to outcome-based. per-seat is already dead 10. The framework that went viral on HN this week: wait 6 months. if it still matters, it'll be obvious what actually compounds instead: - context engineering - tool design - orchestrator-subagent pattern - eval discipline - the harness mindset (harness > model, always) - MCP as the protocol layer be few steps ahead than your competitors and outperform this market till it became mass-opinion study this.

@goldfinch2405 i am about to launch the harness and the automation around it very soon, and most of the developer discipline required will be gone

That’s a very fair question. And honestly no, I’m not claiming Trace can perfectly reconstruct the “why” from repo history alone. This actually came from my own frustration. I kept coming back to projects after a few days and wasting time just trying to remember what I was doing. Right now Trace looks at things like- files you touched ,commit patterns ,timing and tries to reconstruct what you were likely working on and not the full intent. It’s not perfect, but even this gets you back into context much faster than starting from scratch. That’s also why I added the quick note “what were you trying to finish?” so it learns your intent over time. The real goal (and what I’m building towards) is the local version that captures activity in real-time …that’s where it gets much closer to the actual “why”. Appreciate you calling this out …!!!

Your best decisions? Poof. Gone. Vanished into the `git blame` abyss. The true cost of forgotten context isn't just wasted time; it's the death of your project's institutional memory. Stop letting brilliance disappear. #DevLife #SoftwareDevelopment Every commit, every PR, every architectural choice has a 'why.' But where does that 'why' go? Not to your wiki. Not to your Jira ticket. It evaporates, leaving future-you (and your team) to guess, re-decide, or worse: re-implement. The result? Endless meetings rehashing old ground. Debugging nightmares where the original intent is a ghost. It's not merely inefficiency; it's a profound erosion of trust and velocity. Your past self would be furious. You've tried wikis, docs, comments. They fail because context isn't a static artifact; it's a living, breathing history of decisions. What if you had a *dedicated memory system* designed specifically for this critical "why"? The problem isn't lack of tools, it's lack of a *dedicated system*. Generic notes apps fail because project context isn't a static entry; it's a dynamic web of interconnected decisions. You need a memory system, not just a scratchpad. We call it Trace. A dedicated digital memory system specifically for builders. It doesn't just store information; it connects the 'why' to the 'what,' ensuring your project's critical decisions are never lost, only understood. Ready to reclaim your project context and banish the 'Why did I do that?' dilemma forever? Discover Trace: Your Dedicated Project Memory System. Learn more: trac-e.world

fair enough i’ve spend the last few months on the exact same problem and can confidently say that the WHY context is the source of reasoning and it was never captured properly in the first place, so we cannot really recreate it but we can capture it, and if we do this properly in a git-native way, and evolve it in the same way as the code, we can turn any repo into a context graph that can produce outcomes only humans were capable so far i’ve already proposed a concept for capturing this in a very simple way, but requires a little bit of developer discipline until you can use it reliably check it out and let me know what you think: github.com/berserkdisrupt…

@saen_dev @JeremyCMorgan take a look as well at a concept that I am using for my coding agents on each repo: github.com/berserkdisrupt…

@JeremyCMorgan Treating context as a versioned engineering artifact instead of prompt text pasted into chat is the mindset shift most teams haven't made. This pattern matters a lot for internal coding assistants that need to respect architecture decisions that change over time.

Most RAG stops at corpus, retrieval, and injection. This small reference implementation adds output and enforcement layers, treating context as a versioned engineering artifact rather than a prompt pasted into chat. A useful pattern if you're designing an internal coding assistant that needs to respect local architecture decisions. github.com/outcomeops/con…

@goldfinch2405 i must admit that the problem definition is spot on

that's a very interesting approach, thanks for sharing! i am also exploring the alignment problem, but with a different approach - the main focus is to capture the context that "lives in people's heads" (as you said in the talk), but in a completely git-native way, so each repo becomes a readable context graph on its own the point is to capture this context during planning and coding sessions with the agents, and to live and evolve with the code, but at the same time not being part of the code even though there are multiple context types, one of the most important ones - the historical reasoning - lives in something I call contextual commits github.com/berserkdisrupt… this approach allowed me to create something very similar to what you demoed without any external data sources (db, graphs, etc.)... just the repo itself and the way we use it, that's why I called it "git native" and asked if you are looking in terms of an open standard with git primitives i will definitely explore the isolated branches approach for the other types of context that inevitably require context files being stored in the repo itself, sounds very clean

@vidimitrov Any data in the repo itself is of course available to the agent, but we have a docs store that uses an isolated branch of the repo to hold non-code context files So it doesn't clutter up your main branch, but it's stored in git and on GitHub alongside the code.

alignment is the bottleneck! amazing talk and demo by @Mappletons highly recommend 🙌 i'm really surprised how you could fit so many good concepts into a single interface... great work from the @GitHubNext team