What does it take to build a Company Agent? Fynd’s Journey from Raju to a Company Brain

This is the story of how a year of experiments with agents, MCP, tools, memory, orchestration and context taught us that building a useful AI teammate takes much more than a good model. It is also the story of how Raju, an internal experiment at Fynd, grew into the idea behind Citadel, a Company Brain for Fynd.

On a warm Sunday in August 2025, I sent Raju what sounded like a simple request: “Hey, check out what people are chatting about in the Fynd channel.” Two weeks of conversations had piled up, carrying unfinished tasks, important decisions, useful links and commitments people had made along the way. These things seem easy to remember when they happen, but become surprisingly difficult to find a few days later.

I asked Raju to make sense of it all. Read through the conversations, pick out the important tasks, find their owners, turn the useful links into reading homework and bring everything together into a crisp agenda for Monday. What would normally require someone to scroll through conversations, open links, make notes and connect the dots was handed over as one task.

Raju did it. And that made me curious. If Raju could understand what had happened, could it also take care of what needed to happen next?

So I gave him a little more work. Schedule the meetings, put the agenda into the invites, add the right people and make sure everyone knew they had to be there. And while Raju was keeping track of everyone else, it also had to make sure I did not forget the meeting myself. None of this was particularly remarkable. Anyone who has worked in a company has done some version of it.

A meeting itself might last half an hour, but around that half hour sits all the coordination required to make it happen. Finding information, connecting decisions, identifying owners, scheduling people and making sure nobody forgets what comes next. At Fynd, we had begun calling this “work behind work.” It was necessary work, but also repetitive work that quietly took time away from the things people actually wanted to get done. By August, taking care of that work had quietly become Raju’s job.

The curious thing was that only a few months earlier, Raju did not exist. There was no company agent inside Slack doing any of this. There was only an idea and one question we could not quite shake:

“Could we build an AI that knew enough about Fynd to become a useful teammate to everyone inside it?”

We did not know the answer. So we began experimenting.

It began in #god-mode-squad

The question took us back to June 2025, when a small group at Fynd started an internal channel called #god-mode-squad. The idea behind it was simple: reduce repetitive work, make coordination cheaper and give people more time for the work that actually needed their attention.

The problem was that company knowledge rarely lived in one place. Some of it was neatly captured in documents. Some lived in Jira tickets. A great deal was buried in Slack conversations. And some of the most useful context existed only in people’s heads, which worked perfectly well until that person went on leave and someone had to figure out why a decision had been made six months ago.

We started wondering whether an AI could make sense of all this scattered knowledge. Could it connect a Slack conversation to a Jira ticket, understand the decisions behind it and know who was responsible for what? One internal note described the idea as a kind of digital twin for operational tasks and decisions. Around the same time, another idea began taking shape: an agentic program bot that could connect to Slack, Jira and other company systems through MCP.

Today, connecting an AI to your work tools does not sound particularly unusual. In June 2025, it was still new territory. Anthropic had launched remote Claude Integrations only a month earlier, and ChatGPT introduced connectors for company data and custom MCP connections on June 4, just two days after #god-mode-squad began.

There was no mature “connect my company to the model” experience we could simply plug into and start using. If we wanted an AI that could understand how work moved through Fynd, we would have to figure out how to give it the right context, connect it to the right systems and make all those pieces work together.

So we started assembling them ourselves.

Before Raju, there were experiments

Raju did not arrive with an architecture diagram or a grand plan. It came together gradually, through a series of experiments that helped us understand what an AI teammate inside a company would actually need. We tried meeting intelligence, Slack summaries, program-management agents, browser tools, MCP tools and different ways of finding information across the company. Some prototypes worked well, some worked only for a while, and some broke sooner than we would have liked. But almost every experiment taught us something useful.

One of the early Slack agents, for instance, could read through a week of conversations and turn them into a review list. It worked surprisingly well. After seeing the result, Farooq wrote, “We will weaponise Richard... the work behind the work needs to be made agentic.” The line was made in a jest, but it captured something we were beginning to realise.

Until then, most of our experiments had focused on retrieving information. You could ask what happened in a channel, get a long thread summarised or find a decision buried somewhere in a conversation. All of that was useful, but it still left the next step to the person asking. The AI could tell you what had happened. It could not yet help much with what needed to happen next.

That distinction started changing the way we thought about the problem. A useful company teammate could not simply be good at finding and summarising information. It needed enough context to understand the situation, the right tools to act on it, and the ability to move between systems when a task required more than one step.

Around the same time, I was experimenting with similar capabilities using Boltic and MCP. By the end of June, the different experiments were beginning to point in the same direction. Building more standalone AI utilities was not enough. If we wanted something that genuinely felt like a teammate, all these capabilities had to come together. It had to understand the company, use the right tools and move across systems without making the person using it think about which integration sat underneath each task.

What had started as a collection of experiments was slowly becoming one idea.

And eventually, that idea got a name: Raju.

Aye Raju

Raju went live inside Fynd in July 2025, and Slack became his first home. At the beginning, his role was fairly straightforward. It helped people understand what had already happened. You could ask him about a busy channel and get a quick summary, have him make sense of a long thread, pull out action items or identify who owned what. If you had been away for a few days, Raju could help you catch up without spending the first hour of your morning scrolling through Slack trying to piece everything together.

But we did not want Raju to feel like another enterprise chatbot sitting quietly inside a company tool so we gave him a personality. There was Hinglish, Bambaiya humour, chai and, every now and then, a little nonsense. At one point, we even wondered whether we had given him too much personality but that became an experiment in itself. If an AI was going to spend its day inside people’s conversations, being useful was only part of the equation. People also had to feel comfortable talking to it.

The personality made Raju approachable, but the most interesting feedback had little to do with the jokes. As people started using him more, their expectations began to change. It was no longer enough for Raju to answer, “Here’s what happened.” People wanted to know, “Why can’t Raju do this?” If it could identify that someone needed to follow up, why could it not send the message? If it knew a meeting needed to happen, why could it not schedule it? If you told him something important today, why could it not keep it in memory?

Eventually, all those questions came down to one much bigger question: Why can’t Raju simply take care of the task instead of explaining how I should take care of it?

That question changed what we thought Raju should be. People were no longer asking for a better way to find information. They were asking for something that could take the next step.

And that was when Raju began moving from something you could ask to something you could delegate to.

From getter to doer

By August, we had a phrase for what was happening: “Raju is no longer just a getter. Raju has upgraded to be a doer as well.” It was a simple way of describing a much bigger shift. A getter could find information and tell you what needed to happen while a doer could actually make it happen.

That meant Raju’s role started expanding. It could create calendar invites, send messages, set reminders, follow up with people, read documents and links, and use different tools to complete a task. Instead of stopping at, “Here’s what I found,” Raju could take the next step. The difference might sound small, but it changed the relationship people had with him. You were no longer just asking Raju questions. You could start giving him work.

And once an AI can act, the possibilities open up quickly. We started thinking about what Raju could become if it did not have to do everything himself. Could Raju remain the general teammate while specialist agents handled specific kinds of work? Could it understand a request, decide which agent or tool was best suited for it, and bring everything together? Instead of building every new capability directly into Raju, could it learn how to orchestrate the right capabilities when it needed them?

These questions were emerging across the AI industry too. Google announced the Agent2Agent protocol in April 2025, proposing that enterprise agents should be able to discover capabilities and collaborate across systems. Anthropic added remote MCP connectivity to its API in May. OpenAI launched ChatGPT agent in July, bringing reasoning and action together. Today, ideas like agents using tools and working with other agents feel familiar. In 2025, they were still taking shape.

We were not trying to invent those ideas. We were trying to understand what happened when you took them out of a demo and put them inside a real company, where information was scattered across systems, different people had different permissions, tasks had real owners and an action had to actually work for it to be useful.

As we were about to discover, that was where things became messy.

The model was not the difficult part

The more Raju could do, the more we discovered something slightly inconvenient: the model itself was often the easy part. The real challenge was making sure Raju understood the situation around a request well enough to respond correctly and, more importantly, act on it.

Take a seemingly simple question: “What should I follow up on?” Before Raju could give you a useful answer, it had to understand what you actually meant. Were you referring to the current Slack thread or the entire channel? How far back should it look? Was there relevant information sitting in Jira? Who were you, what were you allowed to access, and who actually owned the task? There was also the possibility that someone had already completed it somewhere else and the update simply had not made its way back to the original conversation.

We spent much of that summer running into different versions of this problem. Every seemingly simple request came with a layer of context around it: the conversation, the person asking, their permissions, relevant information from other systems, the tools available and the history of what had already happened. Giving Raju more capabilities was relatively straightforward. Giving him the right context at the right moment was much harder.

Later that year, the industry increasingly began describing this kind of work as context engineering: deciding which instructions, history, tools and external information an agent should have available for a particular task. Anthropic published a detailed engineering piece about the concept in September 2025.

We had arrived at the same problem in a much less formal way. Nobody walked into the room and said, “We need a context-engineering architecture.”

It was usually closer to:

“Why does Raju have the wrong context again?”

Sometimes you encounter the problem long before you learn what to call it.

A company agent must also know the person

As people used Raju more, we learned something else. A company-wide AI could answer impressive questions, but impressive answers were not always where people felt the greatest value. What people really noticed was when a piece of work simply disappeared from their plate. A follow-up was taken care of. A task they had forgotten resurfaced at the right time. Something that would normally require ten minutes of searching or coordination was already done.

That insight pushed us towards what we called Personal Raju. Until then, Raju had largely understood the company and the conversations happening around it. Now the ambition became more individual. Could Raju know what you were working on, bring your tasks together, remember how you preferred to work and help you follow up on things that needed your attention? Could it take actions on your behalf? And eventually, could it surface something important before you even remembered to ask?

That sounded like a natural next step, but it raised a harder question: what should Raju actually remember? Memory could not simply mean “remember everything.” Some information mattered only for the current conversation, while other information might be useful weeks later. We had to think about what should follow someone from one task to another, how long that information should remain relevant, and what should happen when a personal preference conflicted with a company rule. Memory was not simply about storing more information. It was about knowing what to remember, when to use it and when to let it go.

Looking back, Raju’s progression could be described in four words:

Getter → Doer → Personal → Proactive

First, Raju could find information. Then he could act on it. Next, he could begin understanding the person he was helping. The natural next step was to anticipate what that person might need and help before they had to ask.

Each step sounded simple, but each one required another layer underneath it. Becoming a doer required tools. Becoming personal required memory and identity. Becoming proactive required enough context to understand what mattered before someone explicitly asked for it.

And that led us to a much bigger realisation. A company agent is really two systems. There is the agent itself, the part that reasons, chooses tools and takes action. Then there is everything that agent needs to know in order to do those things well: the company’s people, products, decisions, history, rules, ownership and ways of working.

We started thinking of that second system as the Company Brain: a layer that could bring together the company’s knowledge, relationships, rules, history and context, so an agent could find what it needed for the task at hand.

Until then, we had been focused on making Raju a better agent. Now we were beginning to see that the bigger challenge was building the knowledge underneath him.

Then the world moved

There is an odd thing about building with AI: a year can feel like a decade. The architecture we chose for Raju made a great deal of sense in 2025. Boltic workflows allowed us to move quickly. An idea could become a workflow, a workflow could become a tool, and before long we could put it inside Slack and see how people actually used it. We did not have to build a large engineering platform before testing whether an idea was useful.

That speed mattered. It allowed us to learn from real behaviour rather than assumptions or architecture diagrams. We could build something, put it in front of people, see where it worked, watch where it failed and improve it. Many of the things we eventually learned about company agents came from being able to experiment this way.

But while Raju was evolving, the world around him was moving just as quickly. Claude Code appeared as a research preview in February 2025 and became generally available in May. It introduced a different way of working with AI. Instead of asking a model for a piece of code and then doing the rest yourself, developers could give an agent a larger engineering task and let it work directly with the codebase to complete it. [7][8]

By 2026, that way of working with agents was beginning to move beyond software development. Anthropic’s Cowork product followed a similar idea: give an agent an outcome, let it work across files and applications, and allow it to figure out the steps required to get there. [9] The interaction was gradually shifting from “tell me how to do this” to “here is what I need done.”

That shift changed expectations inside Fynd too. Once you have used an agent that can take a messy goal, understand its environment, choose the right tools and work its way towards an outcome, you start expecting other agents to work the same way. You care less about how the system is built underneath. You simply want to give it a task and trust that it can figure out what needs to happen next.

Raju continued getting better, but underneath, it was still built around many of the workflow decisions we had made when the experiment first began. Adding another capability was possible. Then another. And another. But as Raju grew, making changes across the entire agent became harder. What had helped us move quickly in the beginning was now making it more difficult to evolve the system as a whole.

There was nothing wrong with those early decisions. They had done exactly what we needed them to do. They helped us ship quickly, put Raju in front of real people and learn what a company teammate actually needed. Without that first architecture, we would not have learned enough to understand what the next one should look like.

The problem was simply that the bar had moved. The models were better, the tools were better and our own understanding of what an agent could be had changed. If we were starting from scratch with everything we now knew, we would build Raju differently.

So we did.

Raju 10x became Citadel

Raju was an experiment that stayed around long enough to become genuinely useful, and the more useful it became, the more people expected from it.

Looking back, what surprises us is how many of the problems we now associate with building company agents were already showing up in our Slack threads in the middle of 2025. We did not always know what to call them or how to solve them. We simply kept running into them as Raju became more capable.

Through all of this, the original mission of #god-mode-squad has remained remarkably simple: reduce repetitive coordination and give people more time for meaningful work. That problem has never really changed.

Neither has the question that started everything:

“Could we build an AI that knew enough about Fynd to become a useful teammate to everyone inside it?”

Raju was our first serious attempt at answering that question. Citadel is what we are building with everything Raju taught us.

A year later, the models are different. The architecture is different. Even the name is different. But the reason for building it has not changed.

Less work behind work. More time for the work that matters.

We are still building the idea from #god-mode-squad

Citadel did not begin because Raju failed. It began because Raju worked well enough to show us what was still missing.

Raju was an experiment that stayed around long enough to become genuinely useful, and the more useful it became, the more people expected from it. Every new expectation pushed us towards another problem we had not fully considered before.

Finding information required better company context. Taking action required tools and verification. Becoming personal required memory and identity. Working across the company required permissions and a clear understanding of ownership. And as Raju took on more work, we needed better skills, observability and evaluations to understand not only what it was doing, but whether it was doing it well. We were learning that a company teammate needs much more than a clever model. It needs an entire system around that model, and an architecture that can keep changing as quickly as the technology itself.

Many of these ideas have since become familiar parts of AI products. Connectors are increasingly expected. MCP is becoming part of the underlying infrastructure. Skills are emerging as a way to give agents specialised capabilities. Agents can move between tools, delegate parts of a task and continue working towards an outcome instead of stopping after a single response. What felt experimental when we began is gradually becoming part of how people expect agents to work.

Looking back, what surprises us is how many of these problems were already showing up in our Slack threads in the middle of 2025. We did not always know what to call them, and we certainly did not always know how to solve them. We simply kept running into them because every time we made Raju more capable, we discovered another thing a real company teammate needed to know or do.

Through all of this, the original mission of #god-mode-squad has remained remarkably simple: reduce repetitive coordination and give people more time for meaningful work. Raju grew, the technology changed, the architecture evolved and eventually the idea became Citadel. But the problem we wanted to solve never really changed.

Neither did the question that started everything:

“Could we build an AI that knew enough about Fynd to become a useful teammate to everyone inside it?”

Raju was our first serious attempt at answering that question. Citadel is what we are building with everything Raju taught us.

A year later, the models are different. The architecture is different. Even the name is different.

But the reason for building it has not changed.

Note: This blog was brought to life with @Citadel, which helped me gather relevant data and translate my ideas into the story you just read.