Properties, photos and amenities from the CRM
Eligible only, by purpose, with formatted text and price
Consumption catalog, one property per row
AI agent, semantic search and portal feed
What it solves
- The agent only offers properties that are for sale or rent and cleared for advertising.
- The client gets readable price, features and photos, not a raw CRM field.
- Website, portals and agent show the same property at the same price.
Business questions it answers
Ask your agent these questions once the case is live.
What you need
- Property CRM connected to Nekt, with photos and amenities
- The eligible property rule by purpose, approved by management
- A public domain for photos, if the feed goes to portals
What you get
- A consumption table with one property per row, eligible ones only
- Text or JSON per property ready for the agent and for semantic search
- XML feed in the portals' standard
- Last load date on every row
Where to activate
The agent cache receives the eligible table by event, with tenant_id, and the agent answers with ready-made text, price and link.
One JSON per property with readable keys goes to the vector index, with a stable id to update and remove properties that left the catalog.
Nekt's XML destination publishes the VrSync feed from the same table, with public photos and per-property highlight.
The eligibility rule is short. The work is in turning nested fields, photos and values into reliable text and keeping the load always fresh. The detailed view has the business rules, the pitfalls and the acceptance test. Or send everything straight to your agent with the Nekt MCP.
The CRM's property record has hundreds of columns, nested amenity and photo fields, values stored as text and properties that cannot be disclosed. An agent reading the raw record offers sold properties, shows 'R$ 0' and sends links to internal photos. Launches, resales and rentals have different rules for available and for price, and each channel needs the property in its own format.
How it is usually done, and the rule
Each row is a mistake that already happened in practice.
Resale: flagged to show on the website and with status Sale, Sale and Rent or In Negotiation, excluding the project category and inactive land. Launch: project category, condition other than used, and flagged for the website. Rental: total rent above zero and below a sanity ceiling (for example, R$ 50 thousand). Each purpose becomes a table or a purpose column.
A property in negotiation stays eligible so the client is not lost, but the agent says it is in negotiation and offers similar ones. Sold, rented, reserved or suspended never enters. A property that does not exist in the catalog is a different answer from an unavailable property.
Values arrive as numbers, as text with a decimal comma or as 'value|BRL' (in Bitrix24). Convert, round and format as R$ 1.250.000,00. A zero or null value becomes a fixed sentence, for example 'Entre em contato para informações de valores.' (contact us for pricing). Launches show 'from'; resales show the value. Condo fee and IPTU (property tax) go in their own fields.
Amenities and features arrive as a structure with dozens of Yes, No or empty fields. Generate a list with only what is Yes or has a value, each item with its Portuguese label ('Piscina', 'Churrasqueira', 'Água: poço artesiano'). Empty fields disappear from the text instead of becoming 'Label:' with no value.
Use only photos flagged to show on the website, with the featured photo first. The URL must be public: photos from a new CRM usually need a base domain for the portal feed. Website links with localhost or from a test environment stay out.
For the agent, one text per property with 'Label: value' separated by commas, starting with the code. For semantic search, one JSON per property with readable keys and the same content as metadata, with a stable property id for updates and deletes. For portals, one row per property already in the VrSync standard. All three come from the same eligible table.
Map the CRM property type to the VrSync PropertyType through a dictionary (apartment, house, townhouse, penthouse, land, office). Title up to 100 characters, description without HTML and without the CDATA closing sequence, up to 3000 characters. Empty transaction becomes sale. Empty bedrooms use rooms plus suites. Year built outside 1800 to 2100 becomes null. Listing highlight comes from the property's portals field.
The agent table never carries the owner's or listing agent's name, phone or document, commission or internal notes. It only holds what can be told to the end client. Expanding what the agent can say is a management decision, recorded.
When the same agent serves more than one brokerage or brand, each row carries the tenant_id and the agent always filters by it. The property cache and the contact cache live in separate tables.
The table runs by event right after the CRM sync, and each row stores the load date. If the load is late beyond the agreed limit, the agent does not confirm availability: it says it will check with a broker.
Who enters the catalog
Real eligibility rules, by purpose, from the CRM record.
Definitions
Pitfalls that already happened
The agent read the whole record and offered properties that were not cleared for advertising or had already been sold.
The agent reads only the eligible table.
A catalog transformation kept the single property code filter used in testing and published a one-property catalog.
Acceptance test with the eligible count against the CRM on every load.
The query feeding the AI shipped with a 10-row limit used during exploration.
Review limits and filters before connecting the table to the agent.
The agent cache carried the active property column but did not filter on it, and the agent offered inactive properties when the instruction failed.
Filter in the table, not in the agent's instruction.
Projects registered in the CRM and not yet published on the website were left out of the catalog while brokers were already selling them.
Union website launches with CRM launches cleared for advertising that are not on the website yet.
Without a ceiling, unrealistic rent values caused by data entry errors entered the rental catalog next to real properties.
Sanity ceiling on the value and a list of blocked properties for correction.
Acceptance test
The case is done when every item passes.
- The number of eligible properties by purpose matches the CRM count applying the same rule (zero difference).
- No sold, rented, reserved, suspended or off-website property appears in the catalog.
- No row has price 'R$ 0', a value with '|BRL' or a link with localhost.
- Every row has the last load date and it is less than 24 hours old.
- No column in the agent table contains an owner's name, phone or document.
Agent package
Paste into Claude, ChatGPT or any client with the Nekt MCP connected.
Property catalog for the agent - Offer only properties from the eligible table. If the property is not in it, it cannot be offered. - Eligible: resale with show on website = Yes and status Sale, Sale and Rent or In Negotiation; launch with project category and condition other than used; rental with rent above zero and below the ceiling. - Property in negotiation: say it is in negotiation and offer similar ones. - Property not found is different from unavailable. Not found: say you did not find it and offer similar ones. Unavailable: say it is no longer available. - Price: use the formatted price from the table. If it comes with the contact-us sentence, do not invent a value. Launches are 'from'. - Never share owner, listing agent, commission or internal note data. - If the last load date is more than <hours> hours old, do not confirm availability: say a broker will confirm. - Always filter by the tenant_id of the brokerage being served. - Price negotiation, offers, documents and scheduled viewings go to a broker. Client exceptions: - <client>: rent ceiling of R$ <value> for rentals. - <client>: properties in category <category> do not enter the agent catalog.
Build the "Property catalog for an AI agent" case in my Nekt workspace following the rules at https://academy.nekt.com/en/industrias/imobiliario/catalogo-imoveis-agente-ia.md. 1) Find the source tables and confirm the columns the rules use. 2) Create a transformation at the stated grain applying every rule. 3) Run the acceptance test and show me the result of each item. 4) Create the case's context document in the workspace, leaving my clients' exceptions open for me to fill in.
Variations
Catalog per available unit from the sales map, with unit type, area and current price table, without reserved units.
A separate contact cache, with the best phone from the single customer base, so the agent recognizes existing clients.
Daily list of properties flagged for the website that were left out of the catalog for lack of photo, price or link, for the listing agent to fix.