Key Takeaways

• AI Integration Over Total Rewrites: Adding large language model capabilities to an enterprise system does not require throwing away existing infrastructure. Obie demonstrates that a mature, battle-tested Spring Boot application can seamlessly adopt a reasoning layer, extending current data and authentication systems rather than replacing them.
• True Agentic Functionality vs. Fixed Chatbots: Unlike rigid, decision-tree chatbots, an agentic AI assistant independently evaluates a user’s request per conversation, dynamically choosing the right tools (e.g., policy document retrieval or onboarding task tracking) while strictly enforcing existing user authorization boundaries.
• Pragmatic, Enterprise-Grade Stack: Obie relies on a reliable, non-exotic production toolchain: Spring Boot for application logic, Google’s Gemini for the LLM layer, pgvector within an existing PostgreSQL setup for semantic searches, and Langfuse for comprehensive conversation observability.
• Clean Architecture Simplifies AI Debugging: Utilizing a mature and composable toolchain like Spring AI allows real-world production challenges—such as refining document context matching or preventing conversational loops—to be resolved with isolated, highly targeted pipeline guardrails.
• Localization is Critical for Daily Adoption: Building an AI tool that naturally understands and responds in the team’s actual workplace dialect (Taglish, in the case of Filipino offices) makes the difference between an AI tool that employees simply humor and one they actively use.

Every HR team knows the pattern: the same handful of questions, over and over. “How many vacation days do I have left?” “What’s the process for filing an expense reimbursement?” “Where’s the onboarding checklist for our new hire?” The answers all exist somewhere, usually scattered across a shared drive, a handful of PDFs, and the institutional memory of whoever’s been around longest. None of it is hard to find if you already know where to look. Most people don’t.

At Orange & Bronze, we decided to fix this the way we fix most engineering problems: build it, ship it, and see if it holds up under real use. The result is Obie, an AI assistant that lives inside Google Chat, answers HR policy questions from our actual company documents, and helps track onboarding progress for new hires. It’s been running in production for months now, and it’s taught us two things worth sharing.

You Don’t Need a Rewrite to Get to AI

Obie didn’t start as a green-field AI project. It started as an existing, mature Spring Boot application, one with its own data layer, its own authentication, its own business logic already built and battle-tested. The temptation with “let’s add AI” projects is often to treat them as an excuse to start over: new stack, new services, new everything. We didn’t do that.

Instead, we treated the large language model as a new layer on top of infrastructure we already trusted. The application’s understanding of who our employees are, what their roles are, and what onboarding tasks are outstanding didn’t need to be reinvented for an AI assistant to use it. We just needed to give the reasoning layer, the part that understands a question in plain English and decides what to do about it, a way to call into what already existed.

This turned out to be the more important lesson of the whole project. A lot of companies sitting on solid, mature enterprise software assume that joining the AI wave means throwing it out and starting fresh. It doesn’t. If your existing systems are well-structured, modernizing them for AI is an extension project, not a replacement project, the same argument we’ve made about legacy modernization more broadly in The Myth of the Total Rewrite. That’s a very different, and much less risky, conversation to have with a business.

What “Agentic” Actually Looks Like Day to Day

Obie isn’t a search box. It’s an assistant that can reason about a request and decide what to do next. Ask it a policy question, and it searches our real, indexed company documents and answers only from what it finds there, rather than guessing or filling gaps with generic knowledge. Ask about your onboarding tasks, and it checks the actual tracking data for your account. Ask a manager about a new hire’s progress, and it knows to check whether the person asking is actually authorized to see that.

This is the “agentic” part: the assistant has a set of tools it can use, and it decides on its own, per conversation, which ones are relevant and when to use them. That’s a meaningfully different experience than a chatbot with a fixed decision tree. It also means the assistant only ever speaks from grounded, real information, which matters enormously when the answers involve company policy and people’s employment details.

The Stack Behind Obie

For the technically curious, here’s what’s actually running under the hood. Obie is built on Java and Spring Boot, the same foundation as the application it grew out of, with Spring AI providing the layer that talks to the language model, Google’s Gemini, and decides which internal tools to call. Company documents are indexed in PostgreSQL using pgvector, which lets Obie search by meaning rather than exact keyword match, so a question phrased loosely still finds the right policy. The whole thing runs in Kubernetes across separate staging and production environments, and integrates directly with the tools our team already lives in: Google Chat for conversation, Google Drive for source documents, and Asana for onboarding task tracking. We also wired in Langfuse for observability, so every conversation, every document Obie retrieves, and every answer it gives is traced and scored, which means quality problems show up as data rather than as a stray complaint days later. Nothing here is a specialized “AI stack” bolted on from scratch, it’s the same enterprise-grade toolchain we’d choose for any serious production system, extended to include a reasoning layer on top.

Each of these choices was deliberate rather than default. We picked Google Chat over a standalone web app because it’s where our team already spends the day, an assistant nobody has to remember to open gets used far more than one that lives in its own tab. We picked pgvector over a dedicated vector database because we already run PostgreSQL in production, and adding a vector search extension to infrastructure we already operate, monitor, and back up beat introducing an entirely new data store to manage. And we picked Kubernetes because it’s the same deployment model the rest of our infrastructure runs on, so Obie inherited our existing scaling, rollout, and recovery practices instead of needing its own. In each case the deciding facto

Spring AI Is Ready for Production, Not Just Demos

The honest version of this story includes the problems we ran into, because that’s where we learned whether the tooling was actually production-grade or just demo-grade.

Getting the right context, not just similar-looking text. Early on, Obie would occasionally answer confidently but incorrectly, pulling the wrong section of a policy document because the way we matched a question to source text wasn’t quite right. The fix turned out to be a targeted, well-understood change to how questions and documents are compared to each other, not a redesign of the retrieval system. That’s the sign of a mature toolchain: real problems have real, contained fixes, instead of forcing you back to the drawing board, and it’s exactly the kind of discipline we’ve written about in AI Makes Code Quality More Crucial Than Ever: clean architecture is what makes AI-era fixes fast instead of risky.

Keeping long conversations honest. In extended back-and-forth conversations, we noticed the assistant could occasionally get stuck in a rut, declining to look something up again after a couple of earlier dead ends, even when the new question deserved a fresh search. We built a safeguard directly into the request pipeline so Obie always re-checks before giving up, rather than assuming the conversation’s history speaks for the present question. Spring AI’s request pipeline is built from composable, stackable pieces, which meant we could add this kind of guardrail cleanly, without touching the core assistant logic at all.

Real infrastructure, not a prototype. Obie runs against a real database, deployed across staging and production environments in Kubernetes, integrated with Google Chat, Google Drive, and Asana, and enforcing real authorization rules about who can see what. None of that is exotic engineering. It’s exactly the kind of infrastructure discipline we’d apply to any production system, and Spring AI fit into that discipline rather than fighting it.

Talking the way our team actually talks. Filipino offices don’t run in pure English, they run in Taglish, switching between English and Tagalog mid-sentence without a second thought. Obie understands and responds naturally in Taglish, because an assistant that only works when employees phrase things in formal, textbook English isn’t actually usable day to day. That’s a small detail on paper, but it’s the difference between a tool people humor and a tool people actually reach for.

What This Means If You’re Sitting on a Mature Application

The pattern we followed with Obie isn’t specific to HR chatbots. Any organization running a solid, well-built application, particularly if it’s already on the Java and Spring ecosystem, has more of a runway toward agentic AI than they might assume, especially with the kind of performance and cost gains we’ve seen from modernizing the Java runtime itself, work that pays off whether or not AI is on the roadmap yet. The core insight is that the AI layer doesn’t need to replace your business logic, your data model, or your authorization rules. It needs to be given access to them, wrapped in enough engineering discipline to behave reliably in production, and tested the way you’d test any other critical system.

That’s also why modernization has to include paying down technical debt along the way, not around it. A codebase carrying years of shortcuts doesn’t just slow ordinary feature work, it’s exactly what keeps a legacy application from being able to safely take on an AI layer at all. Modernizing isn’t only about unlocking AI: it’s what lets innovation keep moving in general, and it’s the difference between a legacy application that can participate in an AI-enabled enterprise and one that’s permanently stuck on the sidelines.

That’s the same rigor Orange & Bronze already brings to enterprise software: solid architecture, real testing, real observability, real security boundaries. Obie is proof that rigor carries directly into the AI layer instead of getting thrown out to make room for it.

Ready to Find Out Where You Stand?

Obie is one proof point, but the bigger opportunity is figuring out what agentic AI could look like on top of the systems you already have. It’s also not the only one: we’ve shipped AI into production elsewhere at O&B too, including automating our own recruitment screening. If you’re wondering whether your own applications could take on that capability without a rewrite, that’s exactly the conversation we’d welcome having.

Orange & Bronze offers an AI Readiness and Maturity Assessment to help you find out: a structured look at your existing architecture, data, and workflows to identify where agentic AI can be layered in with the least risk and the fastest path to value, and where the groundwork needs to be laid first. Data foundations are usually the part worth checking earliest: as we’ve written, AI doesn’t fix data problems, it magnifies them, so the assessment is also about finding the data issues worth fixing incrementally now, before they become the thing standing between you and a data-centric future.

And because tooling only gets you so far without a team that knows how to use it well, O&B Academy offers AI Readiness Training built for engineering, QA, and executive audiences alike, so your developers know how to build and test AI-augmented systems responsibly, and your leadership knows what questions to ask and what to expect.

Reach out to Orange & Bronze to start with an assessment, bring your team through Academy training, or just talk through what modernization could look like for your systems.