The AI operating layer for the physical environment
Intelligence needs a place to act.
ALYT is the persistent intelligence, context and execution layer for physical spaces. It connects fragmented devices and systems into an environment AI can understand and act through—with permissions and evidence in the loop.
Built on 20 years of the team’s experience connecting the physical world—before “IoT” became everyday language.
Robots give AI a body. ALYT gives AI the environment.
A model may understand what you want. It still needs to know what exists here, where it is, what state it reports, what it can do and what you are allowed to change. ALYT maintains that foundation across supported systems.
Embodied AI puts intelligence in a machine. ALYT puts intelligence in the environment.
Intelligence can change. Rooms, capabilities, state and permission still need a persistent owner. ALYT supplies the contextual model and governed execution layer between intelligence and the physical space.
Intelligence + applications
Models. Agents. Applications. Future robots.
AI models
Autonomous software
OEM intelligence
Robotics direction
Public APIs serve applications today. Richer agent context and robotics interfaces are platform direction; specific connections require implementation and qualification.
↕
Scoped context and bounded requests · governed by ALYT
The persistent environment layer
Context + physical intelligence + policy
Context
Rooms · Devices · Capabilities · State · History · Presence evidence
Physical intelligence
Interpret relevant context and propose bounded intent; defined rules take their direct path.
Policy + permissions
Current access · Capability limits · Approval boundaries
Execution + outcome verification
Supported controls and local routines reach devices through connectors. Fresh reported state and command outcomes provide evidence; an acknowledgement alone is not physical proof.
Simone · Resident intelligence · Simone is ALYT’s resident environmental intelligence. Voice is one interface; ALYT owns state and execution whichever intelligence is involved.
A direct path for defined rules
Local routines and sensor-based reactions use their own control path. They do not need a language-model decision for each event.
↕
The physical environment
Lighting
Climate
Security
Cameras
Access
Energy
Audio
Blinds
Sensors
Appliances
Matter · Thread · Zigbee · Bluetooth LE · Wi-Fi · Local networks · Supported APIs
Conceptual architecture. Supported local controls need power and working connections; online integrations keep their internet requirements.
Context that keeps moving
Sense → Understand → Reason → Govern → Act → Verify
A persistent loop, closed by available evidence. Defined rules take a direct path; models add interpretation when useful.
01Sense
02Understand
03Reason
04Govern
05Act
06Verify
Verification depends on available observations. Missing or stale evidence stays unconfirmed; defined rules do not wait for a model.
The model can change. The environment keeps its context.
ALYT is not competing to be the strongest foundation model. It provides what a model generally does not own: persistent environmental knowledge, shared capability semantics, current authority and a physical execution path. Supported intelligence can build on that foundation.
Physical intelligence in action
The difference context makes.
A command reaches a device. Context connects a situation to the space.
An illustrative environment
“We’re going to watch a movie.”
Living roomLights + blinds + TV
OfficeRecent activity evidence
Allowed actionsRoom-scoped controls
Architecture illustration · richer agent behavior in development
Prepare this room. Leave that one alone.
Separate apps see lights, blinds and a TV. A contextual system also sees a reason to leave another room untouched.
01
Understand the place
Relevant room, current media state and available controls.
02
Respect the exception
Another room appears occupied; keep its devices unchanged.
03
Coordinate + check
Request permitted actions and inspect the resulting evidence.
Broad-goal interpretation and occupancy-aware planning are in development; configured routines provide coordination today.
An illustrative environment
New evidence: activity in the office has settled.
Earlier decisionOffice left untouched
New evidenceActivity has changed
PolicyRecheck before acting
Architecture illustration · richer agent behavior in development
An exception has a reason. Reasons can change.
A fixed scene waits for another command. Persistent context can prompt a new look at the reason a room was excluded.
01
Remember why
Keep the exception and the evidence behind it.
02
Reevaluate, cautiously
Quiet is not proof of an empty room; uncertainty remains.
03
Stay within authority
Only a permitted, supported response may follow.
Event-driven goal reevaluation is architectural direction; this is not a released autonomous household behavior.
An illustrative environment
“Should I leave the windows open tonight?”
OutsideForecast + rain risk
InsideTemperature + HVAC
WindowsState + presence evidence
Architecture illustration · richer agent behavior in development
Weather meets the room it matters to.
A forecast alone does not know the house. A house reading alone does not know the night ahead.
01
Combine relevant knowledge
Use authorized weather information with current indoor readings.
02
Make the limits visible
Which windows report state? What is stale or unknown?
03
Advise in context
Explain a recommendation; changing anything still needs permission.
Combining external knowledge with this richer household context is a development direction, not an available universal weather agent.
An illustrative environment
“We’re heading out.”
PresenceEvidence, not certainty
PerimeterDoors + windows
Critical loadsKeep-on constraints
Architecture illustration · richer agent behavior in development
Same words. A different house each time.
One fixed automation cannot account for a guest still inside, an open window or a load that must stay on.
01
Read the current situation
Consider lights, climate, security state and relevant presence evidence.
02
Preserve the boundaries
Keep critical loads and security’s own authority intact.
03
Propose a bounded response
Coordinate supported actions only after required authorization.
Goal-based planning is in development. A saved Away routine follows the sequence and conditions you configure today.
An illustrative environment
A door opens downstairs at 02:13.
Security modeCurrent confirmed mode
Recent signalsDoor + motion
PresenceKnown evidence + gaps
Architecture illustration · richer agent behavior in development
An event becomes a situation.
“Motion detected” tells you a signal arrived. Time, security mode and recent activity help explain what needs attention.
01
Keep protection immediate
Deterministic security rules respond through their own path.
02
Add relevant context
Relate the event to timing and other available observations.
03
Report with uncertainty
Explain what is observed and what remains unknown.
Sensor-based protection exists today. Richer AI event interpretation is in development and never replaces alarm rules.
An illustrative environment
TV responds. Blinds report closed. One lamp is silent.
TVReported on
BlindsReported closed
LampUnconfirmed
Current foundation · supported controls and reported outcomes
Sent is a command. Done needs evidence.
Sending three commands is not three confirmed outcomes. A truthful response preserves the missing result.
01
Separate intent from state
Keep the request distinct from the device’s report.
02
Inspect each outcome
Use supported results and fresh state, not the dispatch count.
03
Keep the gap visible
The lamp stays unconfirmed; readback proves only what is observed.
Reported state and supported command outcomes are current foundations; this multi-device scene is illustrative, not a physical test receipt.
An illustrative environment
An agent—or a future robot—enters the space.
EnvironmentRooms + capabilities
Live contextState + events
AuthorityScoped allowed actions
Architecture illustration · richer agent behavior in development
A place it can understand. Boundaries it must respect.
Integrating every device from scratch repeats the same work. An authorized environment interface can supply the common foundation.
01
Read the authorized model
Query supported rooms, capabilities and reported state.
02
Request through ALYT
Application permissions and capability contracts govern controls.
03
Add perception where needed
A future robot combines the interface with its own observations.
Applications use public APIs today. Richer agent tools and robotics are platform direction; no deployed robot integration is claimed.
An illustrative environment
The safety system responds. What do we know about the space?
Safety systemIts own immediate path
Occupied zonesRecent evidence only
Other zonesUnknown stays unknown
Architecture illustration · richer agent behavior in development
Protection acts. Intelligence adds context.
A safety signal must not wait for a language model. Additional context can help explain the situation without deciding the alarm response.
01
Preserve safety ownership
Certified alarms and deterministic control keep their own responsibilities.
02
Expose available evidence
Summarize relevant zones and the age of observations.
03
Name the unknowns
Do not infer that a quiet room is empty or safe.
Architectural illustration, not a certified life-safety feature, evacuation system or occupant-location guarantee.
Illustrations of the architecture, not recordings of autonomous operation. Capabilities, permissions and evidence depend on the installation.
For AI, robotics and product teams
One governed interface to the physical environment.
An AI does not need another device API. It needs an understanding of the place—and a reliable way to request an allowed action. Build on ALYT’s rooms, capabilities, state, events and controls instead of rebuilding every integration for every property.
AI agents + autonomous software
Use the published API to read supported state and request scoped controls. Richer contextual views and bounded agent proposals are in development; availability follows the published contract.
Robotics, as a platform direction
An ALYT-enabled space can provide an authorized machine-readable model of rooms, capabilities, state and allowed actions. A future robot could use that interface alongside its own perception. No deployed robot integration is claimed.
OEM + physical-world applications
Connect product intelligence, security and building applications to common capabilities and governed controls. Embedded deployments, model placement and support are scoped and qualified per project.
Commands + evidence
ALYT keeps execution authority. Supported command outcomes and reported state can be inspected; the evidence confirms only what the device or adapter can observe. Unknown stays unknown.
The physical layer keeps its own footing.
Supported local controls and saved routines have their own execution path with power and working connections. Cloud-only services retain their internet requirements. Model placement and platform hosting are separate choices.
Build today. Shape what comes next.
Public APIs, SDKs, supported events and the sandbox are available today. Richer environment context and agent proposals are in development. Robotics and embedded deployments are qualified per project.
Rooms, devices, capabilities, reported state, recent history and access form a living contextual model. Presence is evidence, not perfect identity or location. Saved routines express intent today; richer goals and planning are in development.
Rooms + capabilities
Room assignments and normalized controls give supported devices a common meaning across manufacturers and protocols.
State + history
Readings and changes remain useful beyond a conversation. Freshness and missing evidence matter as much as the latest value.
Presence + goals
Signals can inform a presence estimate; household membership is not location proof. Saved routines express intent today; richer goal-aware planning is in development.
Permissions + policy
Current access and capability contracts govern actions. A model cannot grant itself permission or certify its own success.
The hub brings ALYT home. Behind it is the persistent environment layer: rooms, normalized capabilities, reported state, permissions and execution. Simone is one intelligence within that architecture; supported applications use the published API. Richer agent tools are in development.
What continues without internet?
Supported local device controls and eligible routines saved to the hub can continue locally. A routine that needs an online service still depends on that service; remote access and cloud content need internet.
Can I have a dedicated self-hosted installation?
Yes, on request for an individual customer with specialist needs, such as a villa, mansion, estate, business or corporate facility. It is a bespoke single-tenant deployment. Scope, infrastructure, branding and support are agreed with ALYT.
Can a partner self-host all their customers on it?
The bespoke self-hosted option is dedicated to one customer tenant. That customer can remain in the partner’s portfolio; the partner’s wider customer base uses ALYT’s standard hosted platform.
Can another AI or robot work with ALYT?
Applications can use ALYT’s public APIs, supported events and scoped controls today. Richer agent context and bounded proposals are in development. Robotics is a platform direction: a future robot could use an authorized environment model alongside its own perception. This is not a deployed robotics integration or a claim that every AI model is already connected.
Can ALYT become part of another company’s product?
The hub is one implementation of the platform. Its architecture is intended to support embedded and dedicated deployments, with the target devices, runtime, model placement, updates and support agreed per project. Contact us to discuss a product integration; availability and qualification depend on the deployment.
Make room for intelligence.
Bring your devices together. Give everyday routines a home. Meet ALYT.
