Agentforce and Einstein read the same Propertybase records your agents work in — so what they are worth depends entirely on whether those records are true. Twopir Consulting fixes the grounding first, then builds the agents, the actions and the guardrails, including the review step that advertising and fair-housing exposure makes non-negotiable. Deterministic work stays deterministic. AI does the judgement.
Trusted by 500+ organizations — including brokerages, property managers and real estate investment groups whose listing, inquiry and transaction data Twopir Consulting makes trustworthy enough to ground AI on.
What We Build With
Almost none of these are model problems. They are data, scope and governance problems that a demo on curated records never surfaces. The pilot works. The org is what fails.
Duplicate listings, statuses hours behind the market, inquiry criteria captured as free text. An agent that reads those records confidently tells a buyer about a property that went under contract on Tuesday — and one such answer costs more trust than a hundred good ones earn.
Property marketing and outreach are regulated speech in most markets, and generated copy can drift into descriptions of who a neighbourhood suits. That is an advertising and fair-housing exposure, and it is the single fastest way to turn an AI project into a legal conversation.
Routing a lead by territory, setting a field, advancing a stage when a document is signed — all of these have exactly one correct answer, and a rule produces it faster, cheaper and identically every time. Reaching for a model here adds cost and variance to a solved problem.
Retrieval that ignores the sharing model surfaces another office's deals, another agent's client, or commission data to somebody who should not have it. An AI layer inherits your permission design — and exposes every gap in it at conversational speed.
A pilot that drafts is safe; the same agent given the ability to send, update records or advance a stage is a different risk entirely. Without an explicit allow-list of actions, scope creeps by demo request rather than by decision.
No baseline before, no logging during, no comparison after. When somebody asks whether the AI is helping, the honest answer is that nobody knows — and a capability nobody can defend gets cut at the next budget review regardless of its merits.
Agentforce is Salesforce's platform for building AI agents that act inside your org, and Einstein is the predictive and generative layer alongside it. On a Propertybase org both of them read the same packaged objects your agents work in — Listing, Property, Inquiry and the transaction records — which is what makes them useful and what makes them dangerous. Grounding in your own records is the entire value proposition: an agent that can see a buyer's stated criteria, their engagement history and your live inventory can do something a general model cannot.
It follows that an AI engagement on this platform is mostly a data engagement. If listings are duplicated because a feed matched on address, if inquiry criteria live in a free-text note, or if statuses lag the market by hours, no amount of prompt design fixes the output — the agent is faithfully reading what you gave it. This is why we treat feed health, deduplication and criteria capture as prerequisites rather than as a later phase, and why the honest first answer to "can we add AI" is sometimes "not yet, and here is what it would take".
Who this is for: technology leaders, operations directors and CRM managers at firms with Propertybase live who want AI that survives contact with production. We help growing and mid-market companies solve complex CRM, integration, and business system challenges, and we work with enterprise organizations facing the same problems at greater scale. The wider platform view is on Salesforce Agentforce; this page is what it means specifically on a real estate data model.
Three ways to automate a decision, and how to tell which one a requirement needs
| A rule | A predictive model | A generative agent | |
|---|---|---|---|
| Use when | There is exactly one correct answer and you can write it down | You want a probability from patterns in your own history | The task is language or judgement over context a rule cannot express |
| Real estate example | Route this inquiry by territory; advance the stage when the agreement is executed | Which open inquiries most resemble those that became appointments | Summarise this buyer's history and draft a follow-up for the agent to review |
| Cost & behaviour | Cheapest, instant, identical every time, auditable by reading it | Moderate; needs enough clean history to train on and periodic revalidation | Highest per call, variable output, requires review before anything client-facing |
| Common mistake | Reaching past it for a model, adding cost and variance to a solved problem | Training it on data whose quality problems it will faithfully learn | Letting it send rather than draft, in a regulated advertising context |
Most brokerage requirements are the first column, and that is a good outcome rather than a disappointing one — see Propertybase automation. AI earns its place on the tasks the first two columns genuinely cannot do.
Firms arrive wanting the second. A meaningful proportion need the first, and nobody budgets for the third — which is why so many pilots are still pilots a year later.
An honest assessment of whether your records can support grounded AI, and what it takes if they cannot. Cheaper than a pilot, and it prevents the failure mode where a model is blamed for a data problem.
Building the agent itself: what it may read, what it may do, what it must escalate, and what a person has to approve. Scoped to one workflow that matters rather than a showcase spanning five.
What turns a pilot into a capability. Logging, review sampling, drift detection and a policy that says who may change the agent's instructions — the work nobody demos and everybody needs.
Property advertising and client outreach are regulated speech in most of the markets our clients operate in, and fair-housing rules in particular constrain how a property or a neighbourhood may be described and who may be targeted. Generated copy drifts toward exactly the phrasing those rules exist to prevent — describing the sort of person a home suits rather than the home — and it does so fluently and at volume. That is a compliance exposure created by the generation step itself, not by anybody's intent.
So every client-facing generative use case we build ships with a human review step and full logging of what was generated, by whom it was approved, and what was actually sent. We are not lawyers and this is not legal advice — your own counsel sets the policy, and requirements differ by jurisdiction. Our job is to make that policy enforceable in the system rather than aspirational in a document, and to make sure the evidence exists if anybody ever asks.
Chosen because each one is genuinely a judgement or language task, sits on data a Propertybase org already holds, and can be reviewed by a person before it reaches a client. Start with one, not five.
The strongest first use case. An agent picking up a lead sees what this buyer wants, what they can afford, what they have looked at and what was said last — instead of reading six months of activity themselves.
Drafts, never sends. The agent writes a first version grounded in this buyer's criteria and your live inventory; a person reads it, adjusts it and approves it before anything leaves the org.
Drafting listing descriptions and marketing copy from structured property data — the use case with the highest volume appeal and the highest compliance exposure, which is why review is built in rather than offered.
Reading transaction state across the pipeline to say which deals are behaving unlike deals that closed. Judgement over context, which is precisely where a model beats a threshold rule.
An agent grounded in your own process documentation, answering the questions new hires ask their team lead. Low risk, entirely internal, and often the fastest route to demonstrating value.
Not glamorous, and usually the majority of the engagement. Everything above is worth exactly as much as the records underneath it, so this is where an honest AI project spends its budget.
Every one of these is a place where an AI answer becomes wrong without anybody noticing. They are also, conveniently, the same eight things a well-run Propertybase org already gets right.
An agent describing inventory is only as current as the last successful sync. A feed that stopped quietly turns a helpful assistant into one confidently recommending a property that is already under contract.
Where listings duplicate because matching ran on address, retrieval returns the same property several times with different statuses — and the agent has no way to know which of them is the real one.
Retrieval must honour record visibility, or an agent becomes a channel around your permission design. Every gap between the role hierarchy and the real org chart is exposed at conversational speed.
Inquiry criteria captured properly is what lets an agent reason about fit. Where the buyer's requirements live in a free-text note, the model is guessing from prose rather than matching against inventory.
Routing, stage gates and SLA clocks stay in Flow. The agent hands off to them rather than reimplementing them, so there is one place where each business rule lives and one place to change it.
Drafted follow-up still has to respect subscription state and campaign rules. An agent that composes a perfect message to somebody who opted out has created a compliance problem, not a conversation.
Internal agents should cite your documented process rather than assert from training. That means the knowledge base has to exist, be current, and be scoped by role — which is usually a documentation project first.
What was read, what was generated, who approved it and what was sent. In a regulated advertising context this is not observability for its own sake — it is the evidence you will want if anybody asks.
The groundwork underneath is Propertybase integration and optimization; the wider platform practice is Salesforce Agentforce.
If nobody measured the workflow before the agent existed, nobody can say afterwards whether it helped — and an AI capability nobody can defend does not survive its first budget review.
Each candidate assigned to a rule, a predictive model or a generative agent — with a written reason. Most requirements turn out to be rules, which is a good outcome: cheaper, instant and identical every time. What survives is the genuine judgement and language work, and that is what we build.
Whether the records can support the use case: duplication, freshness, structured criteria, field definitions and the sharing model retrieval will inherit. Where they cannot, this stage produces the remediation scope rather than a disappointing pilot three months later.
What the agent may read, what it may do, what it must escalate, and what a person has to approve — decided and written before any prompt work. Client-facing generative output gets a mandatory review step, because property advertising is regulated speech and generation is where that exposure is created.
One workflow that matters, not five that demo well. We measure the current workflow before launch so improvement is provable, run the agent with a defined user group, and sample its output for quality rather than assuming it. Failure modes are found here, deliberately, not in front of a client.
Logging of everything read, generated, approved and sent; a sampling and review routine; change control on prompts and permitted actions; and periodic revalidation as inventory, policy and the underlying models change. Only then does a second use case get added.
No AI performance figures are claimed on this page — we have none measured on a Propertybase Agentforce build, and we will not invent one. What we can show is the deterministic groundwork any grounded agent depends on, with the numbers those clients measured.
We had Salesforce. We had Propertybase. We had agents using three different follow-up tools. Nothing was connected, and our managing broker was flying blind. Twopir came in, mapped everything, and built a single operating model that our entire team actually uses. We went from not knowing where deals were to having a live dashboard that tells us exactly what's open, what's at risk, and what closed last week.
Real-time MLS synchronisation and deduplication — the inventory accuracy any grounded agent has to read from.
Commission reconciliation used to take our back office three full days at the end of every month. Agents were questioning their splits, and we had no clean audit trail. Twopir connected our deal records to Accounting Seed and built automated disbursement workflows. We now close commission statements the same day a transaction closes. The trust that has rebuilt with our agents because of that alone has been significant.
Deal and commission records made authoritative — the structured history a risk or scoring model would train on.
Twopir Consulting is a Salesforce Partner and a HubSpot Partner. Most of what brokerages hope to solve with AI is solved better, cheaper and more predictably by automation they already own — and hearing that first is what makes the remaining AI work worth funding.
Duplicated inventory, stale statuses and criteria buried in free text produce confident wrong answers no prompt can repair. On this platform an AI engagement is mostly a data engagement, and we would rather say that at the start.
Routing by territory, advancing a stage on execution, running an SLA clock — one correct answer each, produced faster and identically by a rule. Reaching for a model there adds cost and variance to something already solved.
Property advertising is regulated speech, and generated copy drifts toward describing who a place suits. Every client-facing use case we build has a human approval step and a full log of what was generated, approved and sent.
An agent that ignores record visibility is a channel around your permission design. We scope grounding to what the viewer is entitled to see, and treat every gap it exposes in the role hierarchy as a finding worth fixing.
Measuring the workflow before the agent exists is the only way to answer whether it helped. Without it, a capability that is genuinely working still gets cut at the first budget review because nobody can defend it.
Yes. Propertybase Salesforce Edition installs as a managed package into your own Salesforce org, so Listing, Property, Inquiry and the transaction records are ordinary Salesforce objects that Agentforce and Einstein can be grounded in — reading the same records your agents work in, and writing activity back. That is the whole advantage of running your real estate model on this platform rather than on a fixed product. The constraint is not technical access; it is data quality. An agent grounded in duplicated inventory and stale statuses is faithfully reporting what you gave it.
Judgement and language tasks, not decisions with one correct answer. The use cases that hold up are: qualifying and summarising an inquiry so an agent picking it up sees what this buyer wants and what has happened; drafting follow-up grounded in real criteria and live inventory, for a person to review; assisting with listing content from structured property data; surfacing deals behaving unlike deals that closed; and answering internal process questions from your own documentation. What should stay as rules is everything deterministic — routing by territory, advancing a stage when an agreement is executed, running an SLA clock. Those are cheaper, instant and identical every time.
Four tests answer it. Is inventory deduplicated, or do listings appear several times because the feed matched on address? Is status current, or does the feed lag the market by hours? Are inquiry criteria in structured fields, or in a free-text note the model has to guess from? And does your sharing model actually describe the firm, since retrieval will honour it exactly and expose every gap in it. Where the answers are no, that is the engagement — and it is cheaper to hear it as a readiness finding than to discover it in a pilot three months later, having blamed the model for a data problem.
With a human review step, yes; without one, we would not build it. Property advertising and client outreach are regulated speech in most markets our clients operate in, and fair-housing rules in particular constrain how a property or neighbourhood may be described and who may be targeted. Generated copy drifts naturally toward describing the sort of person a home suits rather than the home itself — fluently, and at volume. So every client-facing generative use case we build drafts rather than sends, routes to a named approver, and logs what was generated, edited, approved and published. We are not lawyers and this is not legal advice: your counsel sets the policy, and it differs by jurisdiction. Our job is to make that policy enforceable in the system rather than aspirational in a document.
Not if retrieval is scoped to the viewer, which is a design decision we make explicitly rather than assume. An AI layer inherits your permission model — and therefore exposes every gap in it, at conversational speed and in plain language. In practice this is one of the more useful side effects of an AI readiness review: asking whether an agent should be able to surface another office's deals or a colleague's client forces a conversation about the sharing model that firms have often been deferring for years. Where the role hierarchy no longer matches the org chart, we treat that as a finding to fix before the agent goes live rather than a risk to accept.
Only if you measured the workflow before the agent existed. We baseline the target workflow at stage four — response time, time spent per inquiry, draft acceptance rate, whatever the use case is actually meant to improve — then compare against it with the same definitions afterwards. We also sample generated output for quality rather than assuming it, and log what was read, generated, approved and sent. This is unglamorous and it is what separates a capability from a pilot: an AI feature nobody can defend with numbers gets cut at the first budget review, however well it is working.
It depends on the use case and on your current Salesforce agreement, and the honest answer is that licensing here changes often enough that you should confirm the current position with Salesforce directly rather than take a figure from a consultancy's website. As an architectural rule of thumb: use cases grounded in records already in your org need less additional infrastructure than ones requiring data unified from systems outside it. Twopir does not resell Salesforce licences, so we have no incentive to tell you that you need more than you do — and we will happily scope a first use case chosen partly because it works within what you already own.
A use case you have been asked to deliver, a pilot that stalled, or a board question about AI you need an architect's answer to. We will tell you which parts are genuinely AI, which are a rule you already own, and what your data needs first.
Salesforce architecture, Propertybase delivery & real estate operations
