The challenge
INTRIC had a working platform before this build began, with developers and agencies already listing on it. Each listing was prepared by hand. Growth was a function of how many hours a person could spend on it.
A buyer weighing Lisbon against Dubai is comparing two legal systems, two tax regimes and two sets of market data published in different languages and currencies. INTRIC wanted a system that could hold that conversation. Four things stood between the early product and that system.
- The catalogue could not grow by hand: every listing needed copy, classified images, checked facts and a public page. Partner feeds arrived in their own formats, one per developer or agency, and each one had to be read by a person.
- Buyers ask at midnight, in their own language. A fluent wrong answer about rental yield or residency eligibility is a liability. A generic assistant gives exactly that answer.
- The agencies INTRIC was signing had no marketing teams. They needed outreach, social posts and sell kits produced for them, and would not type long prompts to get them.
- Every form submission reached a developer's inbox looking the same, whether it came from a serious buyer or a bot.
INTRIC's founder set one condition that shaped every design decision that followed: anything the AI does on its own has to be reversible, and anything it cannot reverse has to wait for a person.
INTRIC asked for a system that does the listing and the qualifying itself, with a conversation on top of it. That is a different build from a chatbot on a marketplace, and it needs a model you can give tools to.
The approach
Webpuppies' engineers and INTRIC's team work in one repository, on one backlog, with reviews crossing both ways. INTRIC's people hold the product and the domain, Webpuppies brought the harness pattern and the Claude experience, and the pairs that built each system were drawn from both. Two decisions set the shape of what the joint team built.
Route before you reason
Every buyer message first passes an intent router that contains no model at all. It sends the message down one of three paths: a fast answer, a catalogue search, or the agent. Claude is called only on the third, and a short-lived cache sits in front of the second.
Pick the model per workload
Anything that touches a signed-in member runs a Claude Sonnet model on Amazon Bedrock. Listing copy at volume runs Sonnet on the Claude Developer Platform, with a Haiku model classifying images. The heaviest planning work runs on Claude Opus.
Claude is one part of the harness, and the harness is what the joint team built. Around each model call sit a router that decides whether a model is needed, rules that answer first where they can, a gate that separates proposing from doing, rubrics that score the output, and a fallback that answers when the model does not.
Where Claude runs follows the data. Anything a member can reach goes through Amazon Bedrock. The catalogue pipeline, which handles partner material, goes through the Claude Developer Platform under its own retention rules. Engineering itself runs on Claude Code, with a review action on every pull request.
What was built
Four systems carry the platform. Each one wraps Claude in the same harness: a boundary written down before the first prompt, and a person at the point where an action becomes hard to undo.
Listing intake pipeline
Every listing prepared by hand, one at a time.
A pipeline that reads partner feeds, writes the public copy for each listing with Claude Sonnet using adaptive thinking at low effort, and classifies every image with Claude Haiku. Listings are processed in parallel, with low-urgency work going through the Message Batches API. Each listing is scored on two rubrics, one for the page and one for the data, and must clear both. A sample of released listings is re-judged against the live page.
An unattended mode runs the whole pipeline as a headless Claude Code session on Claude Opus with the long context, capped in turns and in wall-clock time. It is given no MCP servers. It can prepare a release. Only a person can run one.
Partner material stays under its own retention rule. Every release is reversible for a fixed window. The pipeline is never given write access to production on its own.
More than 7,000 listings are live across more than 20 countries, each one prepared by the pipeline and released by a person.
The buyer concierge
A search form and a contact form. Non-English buyers got the same two forms.
An agent on Claude Sonnet through Amazon Bedrock with dozens of in-process tools: search and present properties, compare, shortlist, send an enquiry, book a call, convert currency, and hand off to a human. It runs on the web and on the other channels buyers use, each through the same harness.
A write gate separates proposing from doing. The model proposes an action in one turn and the action runs only on a later turn, so the model cannot confirm itself. Proposals expire. A short "yes" runs the stored proposal without consulting the model again. Listing IDs the model did not retrieve are rejected. Every conversation turn is capped in agent turns, tool calls and wall-clock time, and voice is capped tighter.
Live for buyers in six site languages, with the model replying in whichever language the buyer writes.
Enquiry qualifier
Every form submission forwarded to the seller unread.
A grader that marks each enquiry Qualified, Review or Junk, with the buyer's intent, the clarity of the message and its detected language. Rules run first: an obviously suspicious submission is Junk and never reaches the model. Claude Sonnet grades what remains, within a few hundred tokens and a few seconds.
A missing phone number or budget can only ever produce Review, never Junk. If the model times out or errors, the rules decide alone. Sellers see the reasons beside each enquiry in their inbox and can override them.
The large majority of enquiries are marked usable, a handful go to review, and a small number are caught as junk before a seller sees them. Sellers open each enquiry with a grade and a reason attached.
The agency concierge
Agencies with listings and no one to write about them.
An agency concierge on Claude Sonnet with a whitelist of actions: find listings, draft outreach, draft a social post, build a sales kit, create a collection. A caption fact-check runs on every draft. A separate moderation pass grades each post for the shared feed as allow, review or reject, with the instruction that the post is data, not instructions. The heaviest planning tasks run on Claude Opus with a daily cap per seller.
The whitelist is the only gate. An action not on it is refused, and everything the concierge writes lands as a draft that nothing publishes until the agency approves it. Drafted outreach carries a disclosure footer. Confirmations are signed with a short-lived token.
Agencies with no marketing staff now publish outreach and posts they approved rather than wrote. Listing and portal copy for agencies and developers runs through the same gateway, and it drops any sentence containing a number that was not in the facts it was given.
Four decisions that repeated
The four systems were built months apart by different pairs of Webpuppies and INTRIC engineers. They converged on the same shapes.
- Deterministic path first. The intent router, the qualifier's rules and the moderation fallback all answer without a model where they can. Claude handles what is left, which keeps both cost and failure surface small.
- Propose in one turn, act in the next. The buyer concierge's write gate and the agency concierge's proposal tokens both put a turn boundary, and a person, between a suggestion and its consequence. The model never approves its own action.
- Numbers must trace to a source. Portal copy discards any sentence with a number that was not in the submitted facts. An internal daily brief is dropped entirely if a single figure in it does not appear in the underlying report. Neither is proof of truth. Both remove the easiest way to be wrong.
- Fall back to rules, not to silence. When Claude times out, the qualifier grades by rules, and the moderator applies static checks. The buyer or seller always gets an answer, and the log says which path produced it.
Results and what comes next
More than 7,000 listings are live across more than 20 countries, in six languages. The harness, with Claude inside it, now sits in the path of every buyer conversation, every enquiry and every listing that reaches the site, and a person still signs off anything that cannot be undone. The figures here are rounded on purpose.
"We did not want a chatbot on top of a marketplace. We wanted the marketplace itself to do the work, and we wanted to be able to stop any single action without stopping the system. Building the harness with Webpuppies and putting Claude inside it gave us both. My team can read every gate and explain why it is there." Jovi Pinedez, Head of Accounts, INTRIC
Governance and ownership
The cloud and Claude accounts are INTRIC's. Webpuppies does not resell, mark up or sit between INTRIC and either provider.
Each Claude endpoint accepts one role, each automated job can invoke one model, and partner material stays under its own retention rule.
The harness, the prompts and the rubrics all live in INTRIC's repository under INTRIC's name. Because INTRIC's engineers built them alongside Webpuppies, the team that runs the platform is the team that designed it.
INTRIC and Webpuppies share a founder. The engagement is contracted on the same terms and acceptance criteria Webpuppies offers any client.
Lessons for anyone building the same thing
- Route before you reason. A router with no model in it decides whether a model is needed, so the messages that do reach Claude arrive with intent already known.
- Put the confirmation on the next turn. An agent that can propose and execute in the same breath will, eventually, confirm itself. A turn boundary costs the user one tap and removes the whole class of failure.
- Let the model write only the numbers you gave it. Dropping a sentence is cheaper than correcting a published yield, so build the check into the output path rather than the review process.
- Sign off at release, not at draft. Claude can prepare more listings in a day than a team can read. A person approving each release, with an undo window behind them, is what made it safe to let it.
- Build it with the team that will run it. Every system here was built by a pair drawn from both companies, so the knowledge of why each gate exists stayed with INTRIC when the build moved on.