Vertical AI operating system built on Macro's MCP — five technical questions, and an offer

[markm-sudo]

I run CRE Resources, a business and commercial real estate brokerage in New Jersey, working transactions in the $500K to $10M band. I am also building the software my own practice runs on, and I would like to build part of it on Macro.

What I am building. MainStreetOS is an AI-native operating platform for independent business brokers and intermediaries. Supabase for Postgres, pgvector and row-level security; Next.js on Vercel; agents as Edge Functions calling OpenRouter. A semantic memory layer sits underneath and is exposed to any AI client over MCP. Live today: a five-agent valuation pipeline that produces USPAP-aligned business valuations, and click-wrap NDA gating that controls which buyers can receive confidential deal material.

Where Macro fits. MainStreetOS does not integrate with CRMs one at a time. It speaks a single adapter contract, and each CRM is an adapter behind it. My first adapter is Daylite, for Apple-native shops. I am replacing my second adapter — it was NetHunt — with Macro.

I chose Macro for one specific reason. The hardest entity in my contract is interaction: calls, meetings, emails, and notes, which are the raw material my semantic memory layer runs on. Neither of the other two CRMs delivers that data by webhook, so both adapters poll and both lose data. Macro produces transcribed calls, unified email, and channel messages as first-class objects and exposes them over a hosted MCP server. That is a materially better foundation than either alternative, and no other CRM in my category ships an MCP server at all.

I start a 30-day pilot on a live $4.5M listing engagement this week. Notion Mail shuts down on 22 September, so Macro becomes my working mail client on that date regardless.

Five technical questions. These are the ones that decide how the adapter is built:

1. Do Bot webhooks fire on entity property changes, or is polling the only reliable path for a two-way sync?
2. Can the CRM pipeline stages be redefined? A brokerage pipeline has no "Demo" or "Trial" stage. If not, is carrying a vertical's own stage vocabulary in a SELECT_STRING property the intended pattern?
3. Are ENTITY properties the right way to model a typed relationship — a person linked to a deal as a buyer under NDA, versus as counsel — and can I query on them?
4. What rate limits apply to the REST API and the MCP server for an integration serving multiple tenants?
5. On AGPLv3: my intent is to recommend Macro to my subscribers and integrate with each subscriber's own instance over the API and MCP, without hosting or forking Macro. I read that as outside the copyleft. Is that the usage pattern you intend for integrators?

What I can offer. I am a working solo operator closing real transactions, not a lab. If it is useful to you, I am happy to be a reference deployment for Macro in a vertical outside software teams, and to document what a brokerage practice actually does with a unified workspace. I am also willing to publish the Macro adapter as open source, so the next vertical builder has a worked example rather than a blank page.

If any of this is interesting, I would welcome thirty minutes with whoever owns the API and MCP surface.

Thanks for building this in the open.

Mark Mueller, CAIBVS™
CRE Resources, LLC
(856) 745-9706 · markm@creresources.biz