OpenOpen

Inspiration

Six months ago, I knew almost nothing about coding or AI. Today, I have built my own projects with AI and entered the developer world. That transformation still feels amazing — almost magical — and I wanted to share it with my family and friends.

OpenClaw was what first pulled me deeply into AI. But learning everything was difficult. I spent weeks discovering GitHub, prompts, permissions, models, and all the constraints required to make an agent work the way I intended.

As I spoke with more non-developer friends, I noticed a bigger problem: most people still treat AI as a chatbot.

They often do not know what to ask, what AI can realistically do, or how to turn a broad goal into something actionable. Some expect too little; others expect it to do everything. Most people do not have the time or interest to learn prompting and developer tools.

That led to the idea behind OpenOpen:

AI is not just a chat box. The hard part is helping ordinary people understand, trust, and use what powerful models can now do.

What OpenOpen does

OpenOpen is an AI action layer for non-developers.

Instead of expecting the user to write the perfect prompt, OpenOpen identifies the outcome they are trying to reach. When the request is clear, it responds directly. When different directions would change the result, it presents a small set of meaningful A/B/C choices plus D for “Something else.”

The user can then review and edit the complete result before anything real happens.

The B+ demo focuses on one complete loop:

The user describes a real outcome naturally.
OpenOpen turns uncertainty into understandable choices.
The user selects or refines a direction.
OpenOpen shows an editable confirmation.
The user separately authorizes the real action.
OpenOpen performs and verifies it.
It returns Evidence and a Receipt.
It updates the confirmed local Markdown record.
It offers the next useful choice.

One complete loop is more valuable than ten half-built features.

The demo proves this through a real Reminder, a private same-account iMessage self-chat, one confirmed Memory import, and one reviewed instruction-only Skill.

How I built it

OpenOpen combines a native Mac app, iMessage, a Rust Core, SwiftUI, local persistent state, Markdown Memory, and a signed conversational PersonaBundle.

The model can interpret natural language, but it cannot grant itself permissions or real-world authority. The Host controls actions using typed state and explicit confirmation boundaries.

Every real action binds its exact content, date, time, time zone, destination, and quantity to a confirmation. If anything changes, the previous confirmation becomes invalid.

The system also handles the situations that are easy to ignore in a prototype:

Turning OpenOpen off stops new model work and actions.
Restarting does not pretend interrupted work succeeded.
Duplicate submissions do not repeat an effect.
An uncertain result is not automatically retried.
Completion requires human-readable Evidence.
Memory changes remain visible, editable, and confirmed.
Skills are reviewed before being enabled and cannot silently gain external authority.

The Mac app and iMessage use the same personality and rules, so OpenOpen remains the same product across both surfaces.

Challenges

The project has been exciting and stressful. The clock kept moving, and I wanted to add more Skills, integrations, animations, and “magical” capabilities.

The hardest decision was removing features.

I chose to do less and go deeper: one real workflow with confirmation, recovery, verification, and installation instead of a collection of impressive demos that were not fully connected.

The deepest technical challenge was deciding where AI should be flexible and where the product must be deterministic. Conversation can tolerate ambiguity. A Reminder, message, permission, Memory update, or other real action cannot.

Many of the hardest problems appeared in retries, stale state, restarts, duplicate submissions, changed confirmations, and ambiguous results. I learned that reliability is not separate from user experience — reliability is user experience.

What I learned

Codex 5.6 helped me find technical and safety problems I would not have seen on my own. It challenged assumptions, discovered edge cases, and continued working through difficult implementation details.

It did not replace product judgment. I still had to define the vision, reduce the scope, decide what should feel natural, and determine where the user must remain in control.

But it allowed someone who knew nothing about coding six months ago to build far beyond what I thought was possible.

The biggest lesson is that the model is not the entire product.

The missing layer is the experience that helps people move from intention to a safe, understandable, and verified outcome.

That is what I am building with OpenOpen.