Artificial intelligence can generate content quickly, but building an AI system that can safely operate inside a real business platform is a much bigger engineering challenge.

That was the challenge behind Mizo, the conversational AI agent built by SoftSages Technology inside Mailzzy.

The idea was simple: instead of asking users to move through multiple screens to create an email campaign, Mizo allows them to describe what they want in natural language. The system then helps turn that request into a structured campaign.

But there was an important requirement.

Mizo should help users create campaigns without giving an AI model unrestricted control over the email-sending process.

This distinction shaped the entire architecture.

Why We Built Mizo

Creating an email campaign traditionally involves several steps.

A user may need to:

Write the subject line
Design the email
Select an audience
Choose a sender
Configure the sending domain
Set a schedule
Review the campaign
Send it

Traditional campaign builders work well, but they also require users to navigate multiple interfaces and make many decisions before they see a completed campaign.

Mizo introduces a conversational approach.

Instead of starting with a builder, the user can describe the campaign in plain language.

For example:

"Create a campaign announcing our new summer collection for existing customers."

Mizo can understand the request and help create the campaign around it.

However, an email campaign is not simply a piece of text.

It contains structured information such as recipients, sender identity, personalization fields, HTML, scheduling details, and other configuration.

A mistake in a paragraph may be easy to fix.

A mistake in the audience could result in thousands of emails being sent to the wrong people.

That is why Mizo was designed around an important principle:

The AI can propose actions, but application code controls critical execution.

What Mizo Is Designed to Do

Mizo acts as a conversational layer on top of the existing Mailzzy platform.

Its responsibilities include helping users:

Create campaign content
Structure email sections
Apply email styling
Identify audiences
Resolve sender information
Check campaign details
Work with schedules
Modify existing campaign content
Review campaign information

The AI does not replace Mailzzy's existing campaign infrastructure.

The existing platform continues to handle important downstream processes such as quota validation, review, queueing, dispatch, deliverability, scheduling, and recipient-level processing.

This approach allowed the team to add conversational AI without rebuilding the complete email marketing system.

Designing a Bounded AI Architecture

One of the most important decisions was to keep the AI's authority limited.

Mizo's architecture can be understood as several separate layers, with each layer responsible for a specific part of the workflow.

1. Request and Input Safety

The first layer verifies the user and checks incoming requests before they reach the AI system.

Authentication is handled by the platform's existing identity system rather than asking the AI layer to interpret credentials.

User credentials are also passed only when needed and are not stored in conversation state or exposed to the model.

The system also uses multiple safety checks to identify potentially unsafe or malicious requests.

2. Conversation and Turn Management

AI conversations are not always linear.

Users can pause, change their minds, ask another question, or continue a previous request later.

Mizo therefore saves important checkpoints during a conversation.

This allows a paused interaction to resume without losing its state.

A conversation-level lock also prevents multiple requests from modifying the same conversation at the same time.

3. Agent Runtime and Tools

Mizo uses an agent that can select the appropriate tools during a conversation.

Rather than giving the model direct access to everything, the platform exposes controlled tools.

For example, tools can be used for:

Creating content
Styling email sections
Reading contact groups
Checking sender identities
Working with campaign records
Managing campaign versions

Tool responses are structured rather than returning large amounts of free-form text.

This helps the system distinguish between different situations, such as:

An action completed successfully
More information is required
User confirmation is required
An error occurred

This structured approach makes the workflow more predictable.

Separating AI Decisions From Critical Actions

One of the strongest architectural principles behind Mizo is the separation between AI reasoning and deterministic application logic.

The model can understand a request such as:

"Send this campaign tomorrow morning."

But the model itself does not get to execute the send.

Instead, the request enters a controlled process.

Before an email can actually be sent, the system checks several conditions.

Human confirmation

The user must explicitly confirm the send.

This is implemented as an actual pause in the workflow rather than simply telling the model in a prompt to ask for confirmation.

The conversation state is saved, and execution continues only after the user provides the required confirmation.

Sending limits

Sending limits are checked using atomic database operations.

This prevents concurrent requests from bypassing the same limit.

Idempotency

The system also uses an idempotency mechanism for outbound requests.

This protects against situations such as:

Double-clicks
Network retries
Replayed requests
Resumed conversations

The goal is simple:

A campaign should not be submitted twice because the same operation was accidentally repeated.

Final validation

Before sending, the campaign is checked again for rendering and compliance requirements.

Unresolved personalization fields and other invalid campaign conditions can therefore be caught before the message reaches recipients.

Creating Better Email Content With Structured Data

One early challenge was deciding what the AI should actually return.

A simple approach would be to ask the model to generate the complete email.

But that creates a problem.

If a user says:

"Change the button to green."

Regenerating the entire email could accidentally change the subject, body copy, layout, or other elements.

Mizo instead separates the meaning of the email from its final rendered HTML.

The content-generation process creates a structured representation containing elements such as:

Subject
Headings
Text blocks
Buttons
Other semantic sections

These sections receive stable identifiers.

That means a later request can target a specific part of the campaign instead of regenerating everything.

For example:

"Make the CTA button green."

can modify the relevant section without unnecessarily changing the rest of the campaign.

This makes conversational editing much more practical.

Making AI-Generated Email HTML Reliable

Email HTML has its own technical challenges.

HTML that looks correct in one environment may behave differently across email clients.

Some email clients have limited CSS support, while fixed layouts can also create problems on smaller screens.

For this reason, Mizo does not simply trust generated HTML.

A deterministic validation process checks the output before it is accepted.

The system checks requirements such as:

Table-based email structure
Inline styles
Fluid widths
Appropriate text sizing
Preserved block identifiers
Valid personalization fields

If the generated output fails validation, the system can send the specific failure back to the component responsible for generating the output.

The broader engineering principle is important:

If a requirement can be checked by code, it should not depend only on a prompt.

Handling Images and Other Slow Operations

Some operations take longer than normal conversational responses.

Image generation is one example.

Instead of forcing the entire conversation to wait for a generated image, Mizo can create a placeholder reference and allow the process to continue.

However, that placeholder cannot be allowed into the final campaign.

Before sending, the system verifies that all required assets have been resolved.

This creates a useful separation:

Conversation speed does not have to determine whether a campaign is ready to send.

Why We Moved Away From a Multi-Agent Design

The original architecture used multiple specialized agents.

One agent could generate content, another could work with audiences, another could handle formatting, and another could participate in the sending workflow.

The approach looked promising during demonstrations.

Real conversations exposed a problem.

Users do not always follow a predictable sequence.

A user might:

Create a campaign
Change the subject
Ask about their audience
Return to the email body
Change the subject again
Ask to undo an earlier change

A rigid multi-agent workflow makes these transitions difficult because every change can require routing between different agents or workflow phases.

The solution was to simplify the architecture.

Mizo moved toward:

One conversational agent + one controlled toolset.

Specialized models were still useful, but instead of acting as separate conversational agents, they became tools that the primary agent could call when necessary.

This resulted in a simpler interaction model.

Keeping Campaign Data Separate From Conversation History

Another important lesson came from handling campaign state.

Conversation history contains everything that was said.

But not everything that was said represents the current truth.

For example, a user might say:

"Schedule it for tomorrow at 10."

Later, they might change it to:

"Actually, make it 2 PM."

The conversation contains both times.

Only one represents the current campaign state.

Mizo therefore creates a factual snapshot from the campaign record at the beginning of each turn.

This can include:

Campaign status
Current subject
Audience information
Sender information
Domain status
Schedule information
Current time in the user's timezone

This leads to an important rule:

When reliable application data exists, the AI should reason from the record rather than trying to reconstruct the truth from conversation history.

Preventing the AI From Inventing Completed Actions

Another challenge with conversational AI is that a model can sometimes describe an action as completed even when the underlying tool was never executed.

For a business application, that can create serious confusion.

Imagine a user is told:

"Your campaign has been scheduled."

But the scheduling operation never actually happened.

Mizo therefore relies on tool execution and tracing to determine whether an operation really occurred.

If a claim does not match the recorded actions, the system can identify the discrepancy rather than simply trusting the generated response.

The goal is not merely to apologize after an incorrect response.

The system should, where appropriate, recover from the problem using the user's original request and verified application state.

Handling Concurrent Operations

Campaign data can also be affected when several operations happen at the same time.

For example, multiple tools might attempt to modify:

Sender information
Sending domain
Reply-to address

at nearly the same time.

If those operations update the same campaign record concurrently, one change could overwrite another.

Mizo addresses this by executing tool operations sequentially within a turn where shared campaign state is involved.

The principle is straightforward:

Performance can be optimized, but correctness of shared state cannot be compromised for speed.

Managing AI Context and Cost

Long conversations create another engineering problem: context size.

If the complete conversation and every generated artifact are repeatedly sent to the model, the system can become:

More expensive
Slower
Less accurate

Mizo therefore avoids putting large artifacts directly into conversation history.

Instead, larger objects can be stored and referenced when needed.

The system also manages conversation windows carefully so that tool calls and their results remain correctly paired.

Models can also be selected according to their role.

A conversational task may not require the same model configuration as complex content generation or email styling.

This allows the system to balance capability, performance, and cost.

Observability: Knowing What Actually Happened

Debugging an AI application is different from debugging a traditional application.

A single user request can involve:

An AI model call
Multiple tool calls
Platform API calls
Policy checks
Validation steps
Safety decisions
Confirmation pauses

Looking at separate log lines can make this difficult to understand.

Mizo therefore uses tracing to connect these activities to a single conversation turn.

This makes it easier to answer questions such as:

Which tool was called?
Did the campaign update succeed?
Why was an action blocked?
Did the send process reach the final stage?
Was a dependency unavailable?
Did the system actually perform the action it described?

Observability became more than a debugging feature. It also supports several safety and recovery mechanisms in the system.

What We Learned From Building Mizo

The engineering work behind Mizo highlighted several broader lessons about building AI-powered business applications.

1. AI does not need unlimited authority

A model can be excellent at understanding user intent without being responsible for every downstream action.

2. Critical rules should live in code

If something is irreversible or financially significant, it should not depend only on instructions given to a model.

3. Structured data makes AI applications easier to control

Returning structured campaign components makes editing, validation, and recovery much easier than treating every response as a finished document.

4. Real conversations are unpredictable

Users revise their requests, change direction, ask questions, and go backward.

AI systems should be designed for this behavior rather than forcing users into rigid workflows.

5. Application state is more reliable than conversation history

The conversation tells us what was discussed.

The database should tell us what is actually true.

6. Every important action should be observable

When an AI system interacts with business infrastructure, knowing what happened is just as important as knowing what the model said.

The Bigger Idea Behind Mizo

The most important lesson from building Mizo is not simply that AI can create email campaigns.

The more interesting challenge is deciding where AI should have authority and where traditional software should take control.

AI is useful for understanding natural language, generating content, interpreting requests, and selecting appropriate tools.

Traditional application logic is better suited for enforcing:

Authentication
Permissions
Validation
Limits
Transactions
Compliance
Confirmation
Idempotency
Final execution

Mizo was designed around this separation.

The AI helps users express what they want.

The application determines what can actually happen.

Conclusion

Building an AI agent for a real business platform involves much more than connecting a language model to an API.

The difficult part is creating the boundaries around the model.

With Mizo, SoftSages Technology approached the problem by combining conversational AI with deterministic application controls, structured campaign data, validation layers, observability, and human confirmation for irreversible actions.

The result is a conversational experience that can simplify email campaign creation while keeping critical operations under the control of the underlying platform.

That approach reflects a broader principle for enterprise AI:

Let AI handle understanding and proposing. Let software enforce rules and execute critical actions.

Engineering Mizo - FAQs

What is Mizo?

Mizo is a conversational AI agent built by SoftSages Technology inside Mailzzy. It helps users create and manage email campaigns through natural-language conversations while keeping critical operations controlled by application logic.

Can Mizo send emails without user confirmation?

No. Mizo does not independently execute an email send. Sending requires an explicit confirmation and passes through deterministic validation and control mechanisms.

Why did Mizo move away from a multi-agent architecture?

The team found that real conversations are not always linear. Users frequently revise or change requests. A single agent with a controlled toolset provided a more flexible approach than routing conversations through multiple specialized agents.

How does Mizo handle email editing?

Email content is represented as structured components with stable identifiers. This allows individual sections to be modified without regenerating the entire campaign.

How does Mizo protect campaign data?

Platform information such as audiences, sender identities, and domains is retrieved using the user's authenticated context rather than relying on cached information. Credentials are not stored in conversational state or provided to the AI model.

Why are deterministic checks important in AI applications?

AI models are probabilistic. Deterministic application code can enforce requirements such as permissions, limits, validation, confirmation, and idempotency consistently.

Is Mizo available inside Mailzzy?

Yes. According to the SoftSages Technology article, Mizo is live inside Mailzzy.

Engineering Mizo: Safe AI Agent for Email Marketing