Two Weeks, One Muse Connector: How ShopBack Built It
By Natalie Ho, Senior Product Manager. What it took to build ShopBack’s connector for Muse, and what seven of our builders learned about building for an AI agent.
Want to try it first? Open Muse and type “Connect ShopBack” in the chat.
In early October, Meta asked if ShopBack would be one of the first connectors for Muse, its personal AI agent, when it launched in Singapore. A connector is the bridge that lets an agent call a service directly. Ask Muse for a hotel, a deal or a place for dinner, and with ShopBack connected, it can get the answer from us, along with the rewards a member can earn.
The timeline was tight: we only had two weeks. But this was a huge opportunity, so we said yes.
More people are starting to plan, compare and decide with personal AI agents, and we have always gone where our members shop. Being one of the first connectors meant our members could get their rewards there from day one, and we would learn early how an agent uses a service like ours.
Here is how we did it in two weeks, and five lessons on building for an agent.
Building a connector this fast was never only an engineering job. It took QA testers running scenario after scenario on the live app, a platform team that rebuilt how our in-store search copes with an agent’s traffic, the sign-in and infrastructure engineers who kept everything safe, and colleagues in comms, marketing and customer service who got everything ready for launch around us.
That is what it looks like when ShopBackers pull in the same direction. It is in our DNA, and it is how we work.
But today’s story will focus more on the seven key builders at the centre of the connector, and what each of them learned along the way.
I’m Natalie, the Senior Product Manager who led the build. The easiest way I found to describe what we were building is this. AI agents like Muse now shop for people. MCP is how a service plugs into them: a short menu of actions, like searching for a hotel deal or creating a tracked link, that the agent can use on its own. Everything that follows is what it took to build that menu, and how the team got there in time. At ShopBack we describe how we work through four traits: Agency, Judgement, Learning Velocity and Tenacity. To ship in two weeks, we needed all four.
Judgement: deciding what had to be very right
With two weeks, you can make four things fine or one thing very good. So the first real decision was not technical. It was choosing what to get right.
I ranked the use cases we could launch with: hotels, the best deal on a product, flights, and deals in shops and restaurants nearby. I judged each one on two questions. Is the reward a meaningful amount of money? And would someone see the value in a single screenshot? Hotels came first. They are among the highest per booking, so the reward is real money, and many booking sites sell the same room, so a side-by-side comparison is worth seeing.
The ranking did more work than I expected. It told QA where to test hardest, and it told the team where to spend the last few late nights. When two fixes competed for the same evening, we did not have to argue. We referred back to the list.
Judgement showed up in other calls too. Aaron, Software Engineer, found that one marketplace partner shows an “up to” reward rate on its store page, because the real rate depends on the product. A person taps through to the product to see the real rate. An agent works from what it is given, so it could take the “up to” figure as the rate for everything. His first instinct was to hide that store from search. Then he thought about what the agent would conclude: that ShopBack does not carry it. “Hiding data doesn’t make an AI behave,” he said. “It makes it guess.” So the team steered it instead, with a warning in the response and a suggested next step pointing to a product-level check.
Learning Velocity: learning how an agent reads
None of us had built for an agent at this scale before, so most of the two weeks went into learning how one reads, and changing what we did each day because of it.
The first lesson was how an agent chooses its tools. So I asked the agent to show its working: every tool it called, and why; understanding its inner workings. A few rounds in, the pattern was clear. An agent decides whether to use a tool before it reads the detail of what the tool can do. If the first line does not sound like the question in front of it, the tool does not get a look in. We rewrote how ShopBack introduces itself, in the words members actually use, like “cheapest flight to Tokyo in March”.
Get Natalie Ho’s stories in your inbox
Join Medium for free to get updates from this writer.
Duc, Software Engineer, who built the shared backend every tool runs on, found that longer instructions barely changed anything. What worked was putting each rule where the agent would read it, at the moment it makes that decision: when it connects, when it picks a tool, and when it reads our response. In early tests, it still handed out store links that earn nothing. Putting “only share tracked links” in the instructions it reads when it connects is what fixed it. “Agents treat what we return as fact,” he said, “so accuracy matters more than ever.”
Ted, Senior Software Engineer, rebuilt travel search for the same reader. Our app fetched every hotel and flight first and filtered at the end, which works when a person scrolls while results load. An agent, on the other hand, waits for one complete answer. So Ted rebuilt the flow to filter first and stop waiting on slow sources. In an app, you fight for the first screen. With an agent, as Ted puts it, “there are no images, no prime display space. Just data.”
Ian, Senior Software Engineer, had the most human lesson. Almost every food question has a place in it, and our outlet data knew where every shop was without knowing where “Tanjong Pagar” was. So he built a small list of Singapore places from public data, and named the search field after how people talk. “Nobody tells an agent ‘latitude 1.30’,” he said. “They say ‘near Bugis’.”
Agency: nobody waited to be asked
Two weeks does not leave room for waiting on someone else’s part.
Seven, Senior Software Engineer, added sign-up to the connector, so someone who has never heard of ShopBack can join from inside the conversation in a few taps. He built it on a sign-in foundation we already had, which meant every other team could build against it straight away without checking each detail with him. “The release was not done at merge,” he said. “It was done when someone who had never seen the page got through it.”
Ed, Senior Software Engineer, owned what an agent is allowed to do once it is connected to a member’s account. Before writing any code, he asked the agent to show him the exact request it was about to make, and designed the limits on our side from there. A member sees one plain-language screen before they connect. “Everything behind it is plumbing,” Ed said. “That screen is the promise.”
That very same instinct ran through the channel the whole team worked in. QA did not wait for a finished build to start testing; they ran scenarios on the live app and asked the agent where each number came from. Engineers picked up problems outside their own service. People answered each other’s questions before anyone had to escalate.
Tenacity: two weeks, weekends included
We kicked off on 5 October. From then on there was a demo every day at 4pm, and at 9pm on weekends, so whatever the engineers improved during the day gave QA something new to break the next morning.
On Saturday, 10 October, Ian’s place search went from weak to working in a single day. On Sunday, 11 October, we took the connector to production. Sign-in, platform, the command-line team and I were all online, fixing issues on the spot. By evening it worked with real accounts. The days after went into testing on the live app, scenario after scenario, until we were confident a member would get a good answer the first time they asked.
Nobody would call those two weeks easy. But everyone knew why we were doing it: so that on day one, members in Singapore could ask Muse about travel, shopping or dining, and get their rewards with the answer.
What it adds up to
Put the seven stories side by side and a few lessons keep coming back. If you are about to build for an agent, these are the ones we would hand you first:
- Write your tool’s description in your members’ words. It is the first thing the agent reads.
- Understand where an agent reads each rule and put it there, and at the moment it decides.
- Give it one complete answer, and let it do the choosing.
- When data could mislead, steer the agent around it.
- Keep the limits on your side, and show the member exactly what they are granting.
Back to the menu
Remember the menu of actions we give the agent? It takes every word on it literally and acts straight away. Most of those two weeks went into making that menu as clear as we could: what the agent reads first, where each rule sits, and which limits stay out of sight altogether.
That took a whole, coordinated team of ShopBackers, from engineering, QA, platform, security, comms, marketing and customer service. Over the coming weeks, each of the seven builders will go deeper into their part of the build here on the blog, so stay tuned for more.
P.S. Want to try it yourself? Open Muse, go to Connectors, select ShopBack and sign in, or simply type “Connect ShopBack” in the chat. How to connect ShopBack in Muse
