Every product starts with an uncomfortable truth.

For us, it was this: by the time an HR admin sits down for an exit interview, it’s often too late to prevent the employee from resigning.

Japan’s shrinking working-age population makes every employee harder to replace. For small and medium-sized businesses with limited HR resources, understanding how people are doing can’t happen only when they’re about to leave.

We kept asking ourselves: how do we turn “How’s everyone doing?” from a gut feeling into something HR teams can actually see and act on, before people walk out the door?

That question led us to build freee Survey–and eventually, connect it to AI agents through MCP (Model Context Protocol). This is the story of what we saw, how we approached it, and what we learned along the way.

 

From “collecting” feedback to “understanding” it

The HR admins we spoke with were constantly firefighting. They rarely had the time to proactively check in on team health. Collecting feedback wasn’t the hardest part. What happened afterward was:

• Employees hesitate to share feedback when they think it may reach their managers.
• Responses pile up without meaningful analysis, so it’s hard to know what to do next.
• Busy admins miss the moment to extend a survey or remind people who haven’t answered.

We built Survey to close that gap. Admins choose who receives a survey and when. Survey sends it, reminds people who haven’t answered, and shows response rates. An admin can choose to send a manual reminder or extend the response window while it’s still open.

Once responses are in, Survey shows scores per employee and sorts them by turnover risk based on their survey scores. Two AI features take it further. One proposes hypotheses about what might be behind an employee’s results. The other turns those hypotheses into a suggested agenda for a follow-up conversation. They’re starting points for a conversation based on the answers employees chose to submit.

A case study on Pasmile Co., Ltd.: The company runs a restaurant in Shinjuku. As their team grew to around 20, the owner received sudden staff resignations and there was no way to keep track of everyone’s concerns. The first survey results were a surprise: The newest staff were very satisfied, but the “sense of growth” score among trusted veterans was lower than expected. When the owner asked about it, they weren’t dissatisfied. They just wanted to keep growing. The owner used Survey’s AI analysis and interview support to open better conversations, and the case study reports a net turnover rate from 45% to an astounding  6% over the last six months.

Pasmile’s story highlights a fundamental shift in how teams handle feedback: a survey shouldn’t just be a static data collection form, but a way to understand employee sentiment in order to take meaningful action. With the core product delivering real impact, our next step was exploring how to make this process better and accessible—which brought us to AI agents.

 

The Journey to MCP

MCP is an open standard that lets AI tools securely talk to external software. Survey didn’t start out as an MCP-enabled project. It started with a much simpler question: how do we get better insight out of employee feedback?

Even with analysis features built in, getting an answer still meant logging in, opening results, and building a report by hand. MCP gave us a way to meet HR where they already work. Instead of navigating screens, an admin can ask an AI agent a question, and the agent queries Survey directly.

But jumping straight into building an MCP integration wasn’t an option. Our systems were originally built for predictable, internal services. An AI agent is completely different: it can ask for things in an unexpected order, phrase requests differently, or call endpoints in ways no internal service ever would.

We found that out while working through the MCP requirements, before writing any MCP code. One example: some of our gRPC endpoints returned many different resources in a single response. That works when you know exactly who’s calling and what they need, but it means the endpoint caters only to that caller/service. Our internal API guidelines push the other way: an API should stay within its own domain, return what belongs to that domain, and leave combining results to the caller. An agent is the caller we can’t predict, so narrow, predictable endpoints were what we needed. These are called reusable APIs.

These requirements made a refactor necessary, so we did that first. We refactored our gRPC layer against those guidelines. Each endpoint now returns one kind of resource, structured the same way across the service, and anything related is fetched with a separate call. Where a response used to bundle several resources together, the caller now asks for each one it needs and puts them together itself. That’s easy enough for a service to do, and it suits an agent, which decides for itself what to ask for and how to put it together.

Along the way we also:

• Standardized request and response shapes
• Drew clearer boundaries around what each service is responsible for
• Removed internal shortcuts that only worked for specific internal callers

With that groundwork in place, building the MCP integration itself went much more smoothly.

The difference for HR is immediate. Getting an answer to a question like “What themes came up in last month’s survey?” used to mean logging in, exporting data, and building a report by hand. Now HR can ask the AI, and the AI queries Survey directly.

The lesson we took from it: designing for a caller we couldn’t predict pushed us toward clearer boundaries, and that work had to come before the feature, not after. Through it all, one principle guided our work: stay grounded in real user pain points, not tech for tech’s sake.

 

The Team Behind It

Survey is built by a cross-functional team of engineers, QAs, and a product manager, working across SRE and Dev. None of this happened because one person had a clever idea in isolation. It happened because we have a specific way of working that made room for it.

There’s no single lead assigning every ticket. Each person takes ownership over their own projects, and there’s a real culture of initiative. If someone notices a problem or a gap, they address it rather than waiting to be asked. When a bug appears or something breaks, nobody spends time figuring out whose fault it was. Someone just owns the fix, posts it in our Slack channel, and whoever has context jumps in to help unblock it.

That doesn’t mean there’s no structure, though. We run regular sync meetings to set sprint goals and check everyone’s bandwidth, deciding together whether to focus on one project or run a few in parallel. We list every task, map who owns it across teams, and work out how to unblock anything that’s stuck. And just as carefully as we plan those syncs, we protect the time in between them. Building something like this takes long, uninterrupted stretches of focus, what’s sometimes called “maker time” (blocks of deep work without meetings). So we run on a 2/3 hybrid model: two days of live syncs (Monday and Wednesday), and three days of async standups posted in Slack, so nobody has to break flow just to give an update. Even story point voting happens async.

Ask around, and that Slack channel comes up more than once as what people like most about working on Survey. It’s less a status-update stream and more a running brainstorm, where anyone can post a problem and jump in with ideas. No formal meeting required.

 

What’s Next?

Shipping MCP wasn’t the finish line. It was the unlock.

Two things on the horizon have the team genuinely fired up.

An attendance-based signal: Survey answers are subjective, and employees may not say everything. We’re building a machine-learning feature that adds objective attendance data (presence or absence on working days). This serves as a second source of data alongside survey results. This will give HR another angle on where to check in, plus suggested actions to consider. Building it meant working in sequence: first training the model with data, then a data mart to feed the trained model for inference.

MCP access for department managers: The agent querying we built for admins is opening up further. Today, Survey is available to admins and HR admins by default. Soon, managers will be able to ask an AI agent about their own team’s survey results. For example, before a 1:1, a manager could ask what themes came up in their team’s latest survey and get talking points back, with no admin middleman required.

We’re also exploring how survey data could combine with other signals across freee, alongside expanding our survey types and refining the core UX.

Shipping MCP was the biggest technical swing we’ve taken on this product so far—but the goal was never just about integrating new technology. It has always been about helping HR understand what’s happening early enough to act, long before an exit interview ever occurs.