Autonomy with limits.
We define what the system knows, what it can do, what it must confirm, and when it must escalate to a person.
Four points where the system stops to check.
Permissions
We define which actions the system can execute. When a request falls outside that scope, we configure what should happen: block it, ask for confirmation, notify, or escalate it when the channel allows.
Information
We limit the sources, data, and operations the system can access. Within that authorized scope, the agent can look up the information it needs for its task. What it can log, and where, is also defined in the architecture.
Human escalation
When a situation exceeds its limits, we can configure the system to stop, ask for confirmation, notify, or escalate to a person depending on the channel and the architecture.
Logging and control
Relevant actions can be logged so you can review what the system did and when, depending on how each project is configured.
Before acting, the system checks whether it's authorized.
ELENA's limits, not a universal promise.
This is a demonstration of how a specific agent's limits are configured — not the guaranteed behavior of every system we build.
- Answer frequently asked questions
- Check availability
- Update an existing appointment
- Access data it isn't authorized to see
- Execute an action outside what's permitted
- State information it doesn't have
- The customer explicitly asks for it
- The request isn't covered by its permissions
- There's relevant ambiguity in what's being asked
Your data isn't a footnote.
Each conversation or action can pass through several parties, depending on how your project is built. We'd rather you know who they are than assume.
STEAMNODE
Designs, builds, and maintains the system. Accesses what's necessary to operate it.
Your infrastructure
Your own server, database, or software, when the project is hosted there.
AI providers
The language model that processes conversations (for example, OpenAI or Anthropic).
Telephony
When voice calls are involved, a telephony infrastructure provider.
Meta / WhatsApp
When the channel is WhatsApp Business, Meta's messaging platform.
CRM and other providers
The software connected to the system, and any other service a specific project requires to work.
We design every project with GDPR principles in mind — minimizing data, limiting access, defining the purpose of each processing activity. This doesn't replace legal advice. If your business handles especially sensitive data (health, minors, financial information), we recommend a specific privacy and security review before building.
How these systems connect with the tools you already use is explained in integrations.
When a person needs to step in, they do.
How that signal reaches your team depends on the channel and the project: it can mean escalating the conversation, notifying the right person, or, when the voice infrastructure allows it, transferring the call. We define it before building, we don't promise it generically.
Limits don't stay fixed on launch day.
Reasonable adjustments to existing rules, permissions, and limits can be part of ongoing maintenance. If the change requires new functionality, an integration, or a new architecture, it's valued as a new implementation.
What people usually ask us about this.
Can the system hallucinate or make up information?
It can happen, as with any system based on language models. That's why we limit what it can state without verification and define when it should escalate instead of answering with uncertainty.
Who's responsible if the system makes a mistake?
It depends on the mistake and on what was agreed for the project. We design limits to reduce risk, but we don't eliminate the possibility of error — no system, human or automated, does.
Is my data safe?
We apply good security practices and limit access to what's necessary to operate. We don't claim a certification we don't have — if your project requires one (ISO 27001, SOC 2, HIPAA, ENS, or another), we evaluate it case by case before starting.
Are you GDPR compliant?
We design every project with GDPR principles in mind: minimizing data, limiting access, defining the purpose of each processing activity. This doesn't replace legal advice. If your sector handles sensitive data (health, minors, financial information), we recommend a specific privacy review.
Where is my data hosted?
It depends on the project's infrastructure: it can be yours, ours, or an AI or telephony provider's, as needed for the system to work. We define and document it before building, without assuming a default location.
Can I see what the system did in each conversation?
Depending on how the project is configured, yes — you can have visibility into the relevant actions. It's not a universal log of absolutely everything that happens, it's what's defined as necessary for your control.