Most AI demos look impressive for a moment.
They can summarize, classify, generate, and respond. But once the first output lands, the question that interests me more is not whether the output looks good.
It is this:
how does the system actually get better from there?
That question is what led me to build Hermes Adaptive Stack.
This started as a learning project, but it quickly became something more personal. I found myself thinking less about “how do I get a model to answer well?” and more about “how do I design a system that improves through review, structure, and reuse?”
A big part of that shift came from Google’s AI SDLC direction and OKF. Both gave me a stronger mental model for thinking about AI beyond one-off prompting. Instead of treating outputs as disposable, they pushed me toward feedback loops, reusable knowledge, and systems that can evolve more intentionally over time.
What became clearer to me while building is that they are useful in different but connected ways.
Google's AI SDLC direction helped me think about the move from casual prompting into something more like agentic engineering: an AI system working inside clearer constraints, better context, and more intentional feedback loops.
OKF made that idea feel much more practical, because it gave me a structured way to represent reusable context and knowledge instead of leaving everything trapped inside prompts, notes, or scattered application state.
I also came into this from a platform engineering / architecture mindset, so I naturally approached it as more than just an interface experiment. Even though this is still a personal learning project, I wanted the setup to feel like a serious starter foundation: simple enough to run locally, but structured enough that it could grow in a sensible way later.
That ended up shaping almost every decision in the project.
Where This Really Started
What I did not want to build was another generic chat interface.
I wanted to explore something more grounded: a workflow where AI could work on real spreadsheet inputs, produce something useful, get reviewed by a human, and then carry that lesson forward into future runs.
That was the shift I cared about most: moving from one-off AI output to something the system could actually learn from.
Once I started thinking about it that way, the whole project changed shape. It became less about asking the model for a clever answer, and more about designing the loop around the model.
The Shape Of The System
Because of my infrastructure background, I wanted the stack to stay practical.
I did not want an overbuilt platform for a personal project. But I also did not want something so lightweight that it taught me nothing about how these systems should be structured.
So I treated Hermes Adaptive Stack as a starter setup with room to scale efficiently.
The stack combines Hermes, TanStack Start, TypeScript, Postgres, RustFS / S3-compatible object storage, OKF, Telegram, and Docker Compose.
That combination mattered to me because it kept the project grounded in real system design concerns. Hermes handles the agent side of the workflow, Postgres holds the fast operational state, S3-compatible storage keeps durable artifacts and exported memory, OKF gives the memory layer structure, and Telegram makes the system feel practical outside the web UI.
I was not trying to make the smallest demo possible. I was trying to make a learning-oriented starter system with clear boundaries and a real path for growth.
The Workflow That Made It Click
This diagram captures the point where the project really started to make sense to me.
The workflow does not stop when Hermes produces an answer. It continues through human review, approved lessons, stored OKF memory, and then into better future runs.
That was the moment the project stopped feeling like an AI demo and started feeling like an actual system.
The model was still important, of course. But the more interesting part became the loop around it: what gets reviewed, what gets kept, what becomes reusable, and what actually helps the next run.
That is where most of the product thinking started to live.
Making The Operator Experience Feel Real
One thing I cared about a lot was that the system should feel practical, not just technically correct.
Pipeline Lab is where the process starts. A spreadsheet comes in, Hermes processes it, and the operator gets something concrete to inspect.
From there, the Review Board became one of the most important parts of the whole project for me.
That is the place where human judgment enters the loop. Instead of assuming the first AI output should automatically become truth, the workflow makes room for approval, revision, or rejection.
And once I had a knowledge view for the stored concepts, the project started to feel much more transparent.
That visibility matters. I did not want “memory” to be some vague hidden thing buried inside prompts or temporary context. I wanted it to be something inspectable.
Why Human Review Changed The Whole Direction
This project reinforced something I believe much more strongly now:
human-in-the-loop design is not a fallback. It is part of what makes the system useful.
What made this workflow interesting was not just that Hermes could summarize or classify a spreadsheet. It was that a human could decide what was worth keeping.
That selective part matters a lot. I did not want the system to remember everything. I wanted it to remember the things a human actually considered worth reusing.
That is a very different way of thinking about AI memory.
Why OKF Became A Big Part Of It
Another major influence was OKF.
What I liked about it was not only the format itself, but the mindset behind it. It encouraged me to think about knowledge as something structured, portable, readable, and reusable.
That was a big step up from the usual pattern of keeping everything trapped inside prompts or scattered across app state.
In this project, that led to a very clear separation between working run artifacts, workflow-run knowledge records, and reviewed lesson memory.
workflow-runs help explain what happened.
lessons help improve what happens next.
That simple separation became one of the strongest architectural ideas in the whole system.
So for me, the relationship became pretty simple:
- AI SDLC gave me the mindset for building a better workflow around AI
- OKF gave me the structure for making that workflow readable, reusable, and agent-friendly
One is more about how you operate and design the system. The other is about how you package and preserve the context that system depends on.
Making It Practical With Telegram
I also wanted the project to feel useful outside the browser.
That is why I added a lightweight Telegram assistant flow for success notifications and daily reports.
A successful run sends something a human can actually read quickly.
And the daily report made the system feel even more grounded for me.
This part taught me a small but important lesson: not every AI product surface needs to be a chat interface.
Sometimes the better product choice is a focused notification or a simple summary that gives a human exactly what they need.
I ended up liking this part more than I expected, because it made the system feel closer to an actual assistant and less like something that only exists inside a dashboard.
The Part That Helped Me Think More Clearly
I also wanted the project to have durable structure behind it, not just nice UI.
That is why the system keeps both workflow artifacts and reusable knowledge in S3-compatible storage.
The separation became very visible once I looked at the actual files.
Working run artifacts live under playground-uploads/.
Workflow-run knowledge lives under knowledge/workflow-runs/.
Reviewed lessons live under knowledge/lessons/.
This was one of the clearest mental-model improvements for me while building:
operational state and reusable memory should not automatically be treated as the same thing.
Once I started separating those responsibilities, the whole system felt easier to reason about.
What I Actually Learned From Building It
The biggest lesson was not really about any single model or tool.
It was that the most interesting part of building AI systems is often the design around the model: the review loop, the structure of memory, the shape of the artifacts, the practical product surface, and the boundary between transient output and reusable knowledge.
If I had to summarize the whole experience in one line, it would be this:
the model is important, but the loop around the model is where the product starts to become real.
That is also why I think this kind of approach matters beyond one project.
The ideas behind Google’s AI SDLC direction and OKF can be adapted to real business workflows where teams want AI systems that are more reviewable, more reusable, and more aligned with how work actually happens.
That could apply to operations, reporting, internal analysis, document workflows, or any process where AI output should be reviewed and improved instead of simply generated once and forgotten.
As a platform-minded person, that is probably the part I am most excited about going forward.
Even a starter AI system can be designed with good boundaries, efficient scaling paths, and a clearer long-term structure.
Final Thoughts
Hermes Adaptive Stack is still a learning project for me.
But it changed how I think about building with AI.
I started with an interest in agentic workflows. I ended up learning much more about review loops, structured memory, and how useful AI systems are shaped by the design around them.
The biggest takeaway I’m leaving with is simple:
AI becomes much more interesting when it is not only generating output, but becoming more useful through review, structure, and reusable knowledge.
That is the direction I want to keep exploring from here.
Still learning, still refining, and definitely motivated to keep developing this further.
Credits
I also want to give proper credit to the ideas and tools that helped shape this project.
Hermes was the agent runtime at the center of the workflow experimentation here.
Google was a major source of guidance and inspiration through OKF and the broader direction around AI-assisted SDLC / AI SDLC.
A big part of why I kept pushing this project further was because those ideas helped me think beyond isolated AI outputs and more toward reusable, review-driven systems.
Stay Tuned
I am planning to release the GitHub repository for this project later, so if this kind of work interests you, stay tuned to my GitHub account: chiqors.
You can also follow me on LinkedIn at chiqors if you want to see more of what I am learning and building beyond dev.to.
Top comments (0)