Skip to main content

​
How It Works

The Zild Platform is built as a multi-tenant AI orchestration layer that connects communication channels, intelligent agents, workflows, and enterprise integrations. At a high level, the execution flow follows this structure: Channel → App → Agent → Workflow → Integration → Response This architecture ensures scalability, modularity, and enterprise-grade control.

​
1. Channel Layer

Channels are the external communication surfaces where end users interact with your AI agents. Supported channel types include:
  • WhatsApp
  • Voice (SIP / Twilio)
  • Webchat
  • Custom API integrations
Each channel is connected to an App inside a tenant. Channels are abstracted from agent logic. This means the same agent can operate across multiple channels without rewriting business rules.

​
2. App Layer

An App represents a configured channel integration within a tenant. Examples:
  • A specific WhatsApp Business number
  • A Twilio Voice number
  • A Webchat widget instance
The App is responsible for:
  • Receiving inbound events (messages, calls)
  • Authenticating the source
  • Normalizing the payload
  • Forwarding structured events to the Agent layer
This abstraction allows multiple Apps to route traffic to the same Agent or different Agents based on configuration.

​
3. Agent Layer

The Agent is the intelligence core of the system. When an event is received, the platform:
  1. Identifies the Tenant
  2. Identifies the App
  3. Loads the configured Agent
  4. Retrieves conversation memory
  5. Executes AI processing
The Agent can:
  • Generate natural language responses
  • Call structured tools
  • Trigger workflows
  • Query external systems
  • Escalate to human operators
  • Modify conversation state
Agents operate with:
  • System instructions
  • Knowledge base
  • Tool definitions
  • Escalation rules
  • Context memory
Agents are stateless at infrastructure level but stateful at conversation level.

​
4. Conversation Engine

Every interaction belongs to a Conversation object. The conversation engine handles:
  • Context persistence
  • Message history
  • Metadata storage
  • Event tracking
  • Workflow triggers
This allows:
  • Context-aware responses
  • Multi-step interactions
  • Cross-channel continuity (when enabled)
Conversation state is isolated per tenant.

​
5. Workflow Engine

After the Agent processes an event, it may trigger structured actions. Workflows can be triggered by:
  • Agent decisions
  • Conversation events
  • Time-based conditions
  • External system callbacks
Workflows can:
  • Send webhooks
  • Update CRM records
  • Create internal tasks
  • Send contracts
  • Escalate to human agents
  • Route conversations
Workflows are deterministic and auditable. This separates AI reasoning from business automation logic.

​
6. Integration Layer

Zild integrates with external systems through:
  • REST APIs
  • Webhooks
  • Telephony providers
  • Messaging providers
  • CRM platforms
  • Internal enterprise systems
Integrations are configured per tenant and secured via:
  • API authentication
  • Signature verification
  • Role-based permissions
This ensures safe communication between Zild and external systems.

​
7. Response Delivery

Once the Agent generates a response and workflows execute:
  1. The platform formats the outbound message
  2. The App maps it to the channel format
  3. The message is delivered back to the user
For Voice channels, this may include:
  • TTS generation
  • Call transfer
  • DTMF handling
For messaging channels, it may include:
  • Structured messages
  • Buttons
  • Media attachments
  • Templates

​
End-to-End Flow Example

Below is a simplified execution sequence:
  1. User sends a WhatsApp message
  2. WhatsApp sends a webhook to the Zild App
  3. Zild validates and normalizes the event
  4. The correct Agent is loaded
  5. Conversation memory is retrieved
  6. The Agent processes input
  7. The Agent triggers a CRM update
  8. A webhook is sent to the CRM
  9. The Agent generates a response
  10. The message is returned to WhatsApp
  11. Conversation state is stored
All steps occur within tenant isolation boundaries.

​
Multi-Tenant Architecture

Zild is fully multi-tenant. Each tenant has:
  • Isolated data
  • Independent agents
  • Independent apps
  • Independent integrations
  • Independent workflows
There is no shared memory between tenants. This architecture allows Zild to support:
  • Multiple companies
  • Multiple departments
  • White-label deployments
  • Enterprise-grade segregation

​
Scalability Model

The platform is designed to scale horizontally. Key architectural properties:
  • Stateless application services
  • Conversation state stored in persistent storage
  • Asynchronous event processing
  • Webhook-based integrations
  • Channel abstraction
This allows the system to handle:
  • High conversation volume
  • Parallel AI execution
  • Multiple active channels per tenant

​
Security and Control

Security is embedded in each layer:
  • API authentication
  • Webhook signature verification
  • Role-based access control
  • Tenant data isolation
  • Conversation logging
  • Event auditing
Zild is designed to meet enterprise operational standards.

​
Summary

Zild works by separating concerns into distinct layers:
  • Channels handle communication
  • Apps handle integration mapping
  • Agents handle intelligence
  • Conversations handle state
  • Workflows handle automation
  • Integrations handle external connectivity
This modular design allows organizations to deploy AI once and scale across channels and departments without rebuilding logic.
Next, continue to:
  • Core Concepts — Object model and terminology
  • Quickstart Guide — Step-by-step implementation
  • Platform Overview — Infrastructure-level documentation