In this release
MCP
Patch (patch-twin)
A new MCP tool patch-twin has been added to ProptechOS MCP, enabling AI agents to update specific fields on existing twins without replacing the full resource.
What it does
- Performs PATCH operations (add, replace, remove) on twin fields
- Supported fields: popularName, littera, status, source
- Supports twin lookup by UUID or popularName (twinRef)
Supported twin types
- RealEstate
- RealEstateComponent (Building)
- BuildingComponent (Room, Storey, etc.)
- Device, Sensor, Actuator
- Asset
- All subclasses of the above (resolved via type hierarchy)
Input parameters
| Parameter | Description |
| twinRef | Twin UUID or popularName |
| operation | ADD, REPLACE, or REMOVE |
| path | Field path — one of /popularName, /littera, /status, /source |
| value | New value to set |
Autonomous Agent Service
Dispatch property
A dispatch mechanism that allows autonomous agents to notify humans when issues require attention. The agent detects issues, decides which channel(s) to use, and signals dispatch. The orchestration layer executes the agent’s dispatch. This works alongside the existing routing system — 1 to 1 agent routing handles agent-to-agent communication, dispatch handles agent-to-human/external notification.
Data Model:
JSON
DispatchConfig {
“id”: UUID,
“type”: SERVICE_OBJECT|EMAIL|SMS,
“recipients“: [“[email protected]”],
“autonomousAgentId”: UUID, // reference to AutonomousAgent
“enabled”: boolean // kill switch without deleting config
}
An agent can have multiple dispatch configs (e.g., one EMAIL and one SMS dispatcher). Severity enum reuses existing values: MINOR, MAJOR, SEVERE.
The system prompt is injected with available dispatch types only — no client-sensitive information (email addresses, phone numbers) is exposed to the LLM. The Agent Troupe holds the full dispatch config and resolves recipients at execution time.
The autonomous agent signals dispatch using a structured block in its response. Multiple dispatch blocks are supported in a single response.
For each dispatch block, agent resolves recipient information from the DispatchConfig, and executes independently:
EMAIL:
Agent applies a static email template using summary + severity, resolves recipients from DispatchConfig, sends email, logs event.
SMS:
Agent applies a static SMS template (compact format) using summary + severity, resolves recipients from DispatchConfig, sends SMS, logs event.
SERVICE_OBJECT:
If the autonomous agent has all required data → create the service object via MCP tool → log event
If data is missing → create a draft Service Object with DRAFT status → save a HITL_REQUIRED message with and missing fields → UI surfaces this for human review
Autonomous Agent Persistence
Agent status is now automatically preserved and restored during service redeployments. Agents that were running before a deployment will seamlessly resume their scheduled routines after restart — no manual intervention required. Previously, all agents would lose their operational state and need to be restarted manually after each deployment.
Breaking changes
No breaking changes
Fixes and minor improvements
No additional functionality changes in this release. This update is focused on the alias behavior adjustment.
