Maria Mail

An AI colleague your company already knows how to use: email Maria a task, follow its governed progress, and receive a finished, auditable attachment in the same thread.

Comment

Inspiration

OpenClaw meets Claude Design, but for business.

What inspired me was actually what these products were missing. When OpenClaw appeared, I kept hearing, “finally, AI that does things.” But the models could already do many of those things. What that reaction exposed was the gap between what AI can do and what people can actually adopt.

For companies, that gap is wider still. They know they want AI, but they do not know how to take it on. Every company does, however, understand a capable colleague they can email.

I saw the same pattern again with Claude Design. It is impressive because it shows how far generative design has come, but I wanted to take that capability beyond the creation environment and turn it into an operational company system.

I also wanted genuine object-level editability. I did not want people to remain dependent on asking the AI to make every change. I wanted an admin to be able to click an asset, move or resize it, replace it, edit the text, and turn the design into something the company could actually own, edit and govern: a reusable, company-approved template that every employee could use through Maria.

The company can decide which parts are fixed brand furniture, which are controlled dynamic fields, and which remain open areas where GPT-5.6 can create freely. Instead of every employee separately using a design tool and producing something different, MariaMail provides company-wide generative design built on reusable, company-approved templates.

Putting an AI safely at the other end of company email also meant making security, auditability, verification and validation part of the core architecture, rather than adding them afterwards.

That is where the idea for MariaMail came from: a genuinely capable colleague at the other end of an email, but with the company—not the model—owning the workflow and its outputs.

What it does

The simple experience

MariaMail gives a company an AI colleague that employees work with through ordinary email. They send Maria a request and any relevant attachments. She understands the intended outcome, completes the work, asks for missing information or approval when necessary, and returns the finished result in the same email thread.

Work

Behind each email, MariaMail creates a durable case in Work. The company can see what Maria understood, what stage the request has reached, what evidence and attachments she used, whether anyone needs to intervene, and what outputs were produced.

It is not a temporary AI conversation; it is a persistent piece of company work.

Studio

In Studio, admins create and approve the document systems Maria uses across the company. They can generate a design with AI, then directly click, edit, move, resize or replace its individual elements without knowing HTML.

They can determine which parts are fixed company furniture, which are controlled dynamic fields, and which remain open for Maria to generate creatively. That turns one-off AI design into reusable, company-wide, company-approved templates.

Audit

In Audit, every material action can be inspected: what happened, which case or record it affected, what evidence was used, what was approved, and what was ultimately delivered.

The employee still gets a natural email reply, while the company retains the visibility needed to trust and verify the work.

MariaMail therefore combines a very simple employee experience with a much deeper company system for consistent outputs, permissions, approvals, verification and accountability.

The intelligence is provided by GPT-5.6 running through an embedded Codex App Server, but MariaMail owns the case, workflow, permissions and final output.

How we built it

I built MariaMail using Alepou, my own open-source environment for developing projects with AI agents.

I first worked with GPT-5.6 to design the complete product, producing 16 planning documents covering everything from the product specification and system architecture to security, testing, visual design and hackathon compliance.

Alepou turned those documents into persistent project context and a dependency-aware task board, linking each task back to the relevant planning documents and creating a continuous loop between design, implementation and verification.

Once the design was ready, I essentially said “go.” Codex worked through the project undisturbed for around 13 hours and produced the base application.

From there, Codex and I worked iteratively until the submission build was complete. By submission, the project had reached roughly 200 tasks. Each task was completed as its own commit, with the SHA returned and the Git diff and audit history preserved.

That structure helped me keep the work organised and inspectable even as the software became much larger than I initially expected.

GPT-5.6 therefore appears at every level of MariaMail: it helped me design the product, Codex helped build it, and GPT-5.6 is the model that powers Maria inside the finished software.

Challenges we ran into

The hardest challenge was finding exactly where to constrain the model.

This appeared throughout the project, not only in document design. When we forced GPT-5.6 to reason and generate directly inside a rigid final-output structure, the result was often technically compliant but noticeably worse.

In Studio, asking it to design directly as a JSON array of editable elements produced poor layouts. The same tension appeared in analysis: if every part of the reasoning was forced too early into strict evidence and output constraints, the model’s ability to explore the problem and identify the important result was reduced.

The key insight was that this should not be treated as a single model call.

MariaMail uses a multi-pass workflow in which GPT-5.6 is called several times for different jobs. An early pass is given enough freedom to understand, reason or design properly. Later passes structure that work, bind claims to available evidence, convert designs into editable elements, and work alongside procedural code to validate calculations, permissions, required fields and output contracts.

For example, Studio first allows GPT-5.6 to create freely in HTML, CSS and SVG. Once a strong design exists, another pass converts it into a structured array of selectable elements that can be moved, resized, replaced, edited or locked.

Similarly, analytical work can first explore the supplied data and candidate interpretations, but every factual claim must subsequently be bound to the actual case evidence and survive deterministic checks before entering the final document.

This became the central balancing act of MariaMail: using AI at full strength during the stages where reasoning and generation matter, while heavily constraining what is allowed to emerge from the complete workflow.

The model contributes intelligence at several points, but it never owns the workflow or unilaterally decides that an output is valid. MariaMail owns the evidence, procedural steps, permissions, approvals, verification and final delivery.

Accomplishments that we're proud of

I am most proud that we found a way to preserve the visual quality of open-ended AI design while turning the result into something genuinely editable.

A normal user can click individual elements, move or resize them, replace assets, edit text, and decide which parts should be fixed, dynamic or left open for future generation. The result is not visually compromised by that editability—it remains comparable to the best generative design tools I have seen.

That capability could have been a complete product by itself: an OpenAI-native answer to the same problem as Claude Design, but built around direct object-level editing and reusable operational templates.

But I am equally proud of the decision not to stop there.

MariaMail is deliberately designed for businesses rather than for an undefined individual user creating one-off outputs. An administrator can turn a generated design into a reusable, company-approved template, and every employee can then access that capability simply by emailing Maria.

That product positioning drove the rest of the engineering.

MariaMail is not a chatbot, a design toy or a generic agent waiting for someone to invent a use for it. It is an opinionated attempt to build AI that really does work inside companies—while the company continues to own the workflow, standards, authority and output.

I am also proud that this idea became a functioning end-to-end system during Build Week, rather than remaining only a strong Studio prototype.

What we learned

More broadly, the gap in business AI is not simply model capability. The models can already do an enormous amount. What is missing is a form companies can actually adopt.

Companies face a mountain of work before AI becomes genuinely useful to them. They need security, auditability, verification and validation, but they also need to preserve the reasoning and generative abilities that made the technology valuable in the first place.

Before they even reach those problems, they have to work out how this unfamiliar technology fits inside their highly specific company environment.

The people who understand AI often do not understand the company. The people who understand the company often do not understand AI.

Bridging that gap can mean hiring teams of consultants who first have to learn how the business works, then attempt to design something that might be useful, safe and adoptable.

What we learned is that MariaMail has to be extremely opinionated.

Instead of asking every company to invent its own way of using an agent, we offer something they already understand: an employee who happens to be AI.

Employees delegate through email. Administrators define the company’s capabilities, templates, rules and authority. MariaMail provides the security, evidence, verification, approval and audit structure around the model, while still allowing GPT-5.6 to reason and create at full strength where that is valuable.

The company should not have to become an expert in AI before AI can become useful inside the company.

What's next for MariaMail

The first thing MariaMail needs next is not another impressive capability. It is the unglamorous work of tightening every bolt.

An AI system reachable through company email has to be exceptionally secure. It will encounter ambiguous requests, unusual attachments, conflicting instructions, malicious inputs and edge cases that challenge even a carefully designed workflow.

MariaMail already demonstrates the philosophy at a meaningful level and genuinely works, but security, verification and procedural correctness cannot honestly be declared solved by one developer and Codex in one week.

The immediate next step is therefore to push the existing system much harder: adversarial testing, permission boundaries, unusual approval paths, interrupted work, malformed evidence, conflicting records and every edge case we can find.

The heavy procedural checking throughout MariaMail is one of its strengths, but it also creates boundaries that need to be tested repeatedly to ensure they do not block valid reasoning or allow invalid outputs through.

After that comes the exciting part: giving Maria more abilities.

She can currently analyse supplied data and produce evidence-linked, company-branded reports; create quotations whose values and approvals are carefully verified; and generate editable presentations and document templates.

Those are the beginnings of a capability library, not the intended limit.

Over time, I would like MariaMail to become something closer to an AI-native operational system for a company—a living equivalent of platforms such as NetSuite, but one that employees interact with naturally and that can reason across the work rather than merely store it.

Maria could understand customers, quotations, projects, documents, approvals and company knowledge, while still keeping every action inside explicit permissions and verifiable workflows.

I deliberately did not attempt to build an entire ERP in one week.

The aim of this build was to establish the more important foundation: an AI colleague that companies can actually adopt, control and trust. From there, her role can expand one carefully verified capability at a time.

Built With

Share this project:

Updates