Structured by design
Entity schemas describe customer, property, appointment and billing records. Declarative definitions describe product surfaces and workflows, giving software a common vocabulary for the business.
Architecture for the agent era
A business your agent
can understand.
Love is an agent-native CRM for recurring home services. JSON schemas describe the records, structured tools make context discoverable, and AI teammate permissions govern access. Your preferred agent works through that interface to investigate the business and propose the next step.
Readable context. Governed work.
Three pieces that
work together.
Discoverable through MCP
The client can inspect the tenant catalog, discover available schemas and use typed tool inputs. Catalog action discovery tells it which action types it can propose instead of guessing a business command.
Bound to a teammate
OAuth binds the connection to an active AI teammate. Love checks its tenant, acting role and capabilities at the API boundary. Catalog action proposals go to Home for human review.
A clear access boundary
Connect a teammate.
Define its responsibility.
An Owner signs in and chooses the AI teammate that should represent an outside connection. The client receives that identity and the permitted tool surface. It does not inherit an Owner role simply because an Owner completed consent.
Use different teammates for different responsibilities. A scheduling role and a billing role can have different access. The role’s read scope matters as much as its assigned actions: permitted records become context the external agent provider can process.
Love rechecks the active teammate and connection. Revoking authorization or deactivating the teammate stops subsequent requests through that connection.
Workspace endpoint
https://your-workspace.lovecrm.co/mcpExample address. Copy your exact URL from Love’s API & MCP setup.
- Transport
- Streamable HTTP
- Sign-in
- OAuth with PKCE
- Identity
- One active AI teammate
From a question to a proposed action
Give agents a contract
for the work.
A customer’s service plan, the appointments it generates and the account history belong to a connected business context. Structured discovery helps the agent understand that context before deciding what to propose.
| Layer | What it describes | Why it helps an agent |
|---|---|---|
| Entity schemas | The shape of business records and their relationships. | Use defined fields and identifiers rather than infer them from a screen. |
| Tenant catalog | The entities, queries and operations in this workspace’s effective pack. | Discover the available business surface before choosing a tool. |
| Catalog actions | Action types available to the selected teammate. | Propose a known business action using its expected contract. |
| Permission policy | Tenant identity, acting role, capabilities and assigned actions. | Keep access inside a server-checked responsibility boundary. |
| Proposal review | A proposed catalog-action run for review in Home. | Give a person a concrete action to assess before it is approved. |
Love still uses a database and APIs. The advantage is the combination of explicit schemas, discovery, business-action contracts and enforced permissions—not a claim that JSON alone removes the need for storage or security.
Human judgment stays in the workflow
A proposal is a useful
place to pause.
The general catalog-action path turns an external agent’s request into a proposed run requiring review in Home. The client cannot approve its own proposal or change the user and teammate governance that sets its authority.
Workflow-specific tools need their own review. Routing collaboration includes solve, draft and apply paths; its controls should be checked before authorizing a scheduling teammate. A universal “all writes are approval-only” promise would miss that distinction.
A useful first delegation
“Review the permitted account history, identify the relevant action, and prepare the next follow-up for me to review.”
Start with one workflow and verify the records and permissions behind the answer. Expand the teammate’s responsibility deliberately.
Explore AI teammate workflowsArchitecture questions
What agent-native
means in practice.
What is an agent-native CRM?
An agent-native CRM exposes understandable business records, tool contracts and governed actions so an agent can work with operational context. In Love, schema-defined entities, workflows and MCP tools sit behind tenant and AI-teammate permission checks.
Does using JSON make a CRM secure?
No. JSON makes contracts easier for software to describe and exchange. Love’s access boundary comes from authentication, tenant checks, role capabilities, assigned actions and server-side policy enforcement.
Does Love replace its database with JSON?
No. Love stores canonical records, projections and an outbox in DynamoDB. Its schema-driven product and structured API let agents discover records and available actions. JSON is a contract format, not a substitute for a database.
Does a connected agent act as the business Owner?
No. An Owner authorizes a hosted connection to one active AI teammate. The teammate must have an allowed non-Owner acting role; the API checks its tenant and permissions rather than giving the external client the consenting Owner’s role.
Does every MCP operation require approval in Home?
Catalog business-action proposals wait for Home review. Routing collaboration has separate draft, solve and apply tools governed by its own capabilities. Review the tools enabled for the chosen teammate instead of assuming one approval rule covers every workflow.
Can employees use their own agents with Love?
A compatible personal client can use an authorized Love teammate connection. Knowing the MCP URL does not authorize access. The Owner should select a teammate with appropriate read permissions and assigned actions, and consider whether the external client shares connections across its agents.