Groundhog day
The hardest part of building agentic systems today isn't intelligence — it's operationalizing them. Every team, every open source project, every agentic prototype is building agentic systems today solving the same problems from scratch.
How does a human operator observe, intervene, respond? How do we track and analyse the agents "thinking" and "actions"? How do we give agents persistent memory? How do we govern agent tool calling?
The answers are being reinvented weekly (if not daily). One team builds a bespoke vector store with hand-rolled retrieval. Another writes custom context management mechanisms. A third creates an elaborate state machine for agent coordination. Each solution is slightly different, incompatible from others or the previous attempt, and usually incomplete. It's not the just agents which are in a loop but we humans are also in a Groundhog day loop: tedious repetition of the same things, same events every iteration.
It makes a team's communication messy as there are no consistent building blocks. It distracts the team from focusing on the customer outcomes, ultimately not creating long term value for the organization or the customer.
This is the "PHP circa 2003" era of agentic systems. Powerful capabilities exist, but there's no cohesive framework that says: here's how you structure an agentic application, here are the components you'll need, here's how they fit together.
Batteries included
We have an opportunity for the Rails moment in AI. Ruby on Rails succeeded not because Ruby was the best language, or because Rails was the most flexible framework. It succeeded because it made a bet: most web applications need the same things, and if we make opinionated choices about those things, developers can focus on what makes their application unique.
The Rails bet included:
- Convention over configuration. File in a certain place? It's a model. Named a certain way? It connects to this table. No XML, no ceremony.
- The golden path. Do things the Rails way, and everything flows. Routing, templating, migrations, mailers - all present, all integrated, all with sensible defaults. Deviate when you need to, but know you're deviating.
- Optimized for the common case. 80% of apps need 80% of the same things. Serve them well.
The result: Builders could go from idea to working application in hours instead of weeks. The framework handled the infrastructure; humans handled the interesting problems.
Agentic systems are ready for the same intervention. What do most agentic systems need?
- Memory. Both working context (what am I doing now?) and long-term recall (what did I learn before?).
- Communication. Agents talking to agents. Agents talking to humans. Async, persistent, addressable.
- Work & Resource management. Tasks, dependencies, state transitions, parallelism without conflicts.
- Decision capture. Why did we do this? What did we consider? The reasoning trail.
- Human oversight. Observation, intervention, correction, approval gates.
Every team building a serious agentic system implements some version of all six. Usually differently in every iteration, because it's not their core focus. This constant, custom rebuilding of essential infrastructure is like a race team having to invent a new Pit Crew for every single pit stop.
AI on Rails is the standardized Pit Crew for your agents, providing the tools and protocols necessary for smooth, fast, and reliable operation. A set of conventions, integrated primitives, and opinionated defaults that let teams build agentic systems without reinventing coordination infrastructure.
In regulated environments like financial services, these primitives aren't optional. Every agent action must be observable, reviewable, and defensible after the fact. Part II will dig deeper into how we at Gopitcrew are building conventions for Vertical AI like Financial services agents.
This article was originally published on LinkedIn. Read it on LinkedIn →