Author’s note: FM Agents is a product my team is building. This piece comes from a change in our product thinking and an early review of the new setup experience. We’re still building and testing it, so I want to be clear about the difference between the direction we’ve chosen and what we’ve proved. — Scott Reyes
My team is building software called FM Agents to perform facilities maintenance processes like calling contractors and gathering information. We started with specific jobs we knew people needed help doing, then customer conversations began pushing us toward a different kind of product.
The first two agent types had fairly defined responsibilities. One agent would follow up with contractors. It could ask for an update, find out when somebody expected to arrive, and put that information back into the work-order process. The other would handle inbound requests. For example, if somebody called to report a broken refrigerator, the agent could gather the necessary information and create a work order.
Those were concrete enough to build and demo. Once we showed people, they eagerly started describing other things they wanted. While their requests were related to what we had built, they didn’t fit neatly inside those two agents.
That became especially clear in a recent discussion with a new customer about handling service problems. In their case, a location might report that service hadn’t happened. The next step would depend on what was wrong, how urgent it was, what the existing records showed, and who needed to respond.
I could see how to build that customer's workflow. The problem was that workflow wouldn’t fit any of our other customers’ workflows. It would be completely custom software.
I didn’t want every new customer conversation to turn into a custom software project. But it was apparent that's what people wanted.
Let the customer describe the process
Around the same time, I had been creating agents for our own work in Grok Bot. It lets me give an AI assistant a job through a conversation. It helps write its own process and connects with the tools it needs to do its work. I wanted to bring that way of setting up a new agent into our FM Agents.
The appeal was that a customer could begin with the work they understood.
I wanted somebody to describe a facilities process in plain language. The setup experience would ask questions, identify the tools and information required, and show the person what the agent was going to do. Then the person could correct it and approve it.
This user experience is superior to learning a new software because this new software works the way they do.
Once we started working through an example, the questions became much more specific. Take a missed arrival time. We need to know which work-order statuses qualify for follow-up. A job waiting on a contractor’s invoice probably shouldn’t get a call asking why the technician hasn’t arrived.
We need to know what counts as a useful answer. Reaching somebody on the phone doesn’t necessarily mean we got the information we needed. If they can’t provide a new arrival time or a meaningful update, the process still needs a next step.
How many unsuccessful attempts should happen before a person gets involved? If the contractor gives a new arrival time, should the agent wait until then? What happens if the situation becomes more urgent in the meantime?
And what about issues that were reported but didn't have a work order associated with them? We needed a queue for that as well.
Those questions belong in setup. I wanted the product to help uncover them instead of assuming the customer had already written a complete specification.
One agent, one repeatable process
We also had to settle what we meant by an agent. That affected both what customers would set up and what our software would need to track.
I wasn’t imagining a separate agent for every open issue. Instead, I imagined a configured process that could run repeatedly, with the relevant context for each case:
-
One contractor-follow-up process could apply to many work orders. Each run would have its own contractor, history, and information to gather.
-
The underlying tools and records would be shared. We weren’t going to create a separate set of contractors, work orders, and issues every time somebody created an agent.
The latter was the larger change. Instead of continuing to add individually built agents, we would work toward a common toolkit and a way for customers to configure a process around it.
I also wanted a firm boundary around what happened after approval.
The running agent should follow the approved process. When something falls outside it, a person needs to get involved. An agent might eventually suggest a useful improvement, but noticing an opportunity shouldn’t give it permission to rewrite its own job. The customer needs to be able to understand what they approved and trust it will continue to hold meaning.
A simpler way to set up the work
The setup experience should be simple. Tell it what you need done, answer the questions that help define the process, and review the instructions before turning it on. The customer shouldn’t have to learn how we built the software to work with it.
That’s what interested me about this direction. Each customer has their unique way of handling facilities maintenance. They know what needs attention, what information matters, and when someone needs to step in. I want to enable them to use that knowledge to configure an agent that works the way they do.
We started by choosing two jobs and building agents to do them. Customer conversations showed us how many other jobs there were. Giving customers a simple way to define those processes lets us support that variety without turning every request into a separate software project.
