Wizzo

• 

  Logo

Inspiration

Most productivity tools are built to record work after a person has already decided what to do. AI chat tools can generate plans, but they often lose context, produce disconnected suggestions, and hide how decisions were made.

I built Wizzo to explore a different model: a human-in-the-loop system that helps people move from intention to action while keeping the user in control.

Wizzo treats goals, projects, decisions, and progress as parts of a living system. Instead of acting like a chatbot attached to a task list, it observes the user’s active work, organizes it into structured workflows, proposes next actions, and learns from the decisions the user accepts or rejects.

What it does

Wizzo is an AI-native planning and execution workspace for managing goals, projects, and personal workflows.

Users can:

• Turn broad goals into structured quests, trials, tasks, and subtasks
• Define dependencies so work happens in the correct order
• Track progress, status, evidence, and completion history
• Create reusable templates for recurring workflows
• Compare performance and activity across projects
• Receive contextual recommendations about what to do next
• Review AI suggestions before they affect the underlying plan

The product is designed around observable intelligence. Recommendations are connected to structured product state rather than being generated from an isolated chat prompt.

Human-in-the-loop decision policy

A central part of Wizzo is its decision-policy architecture.

The policy evaluates available context and determines which action, recommendation, or workflow transition may be most appropriate. However, the system does not silently take control away from the user.

The current production version runs the decision policy in an off-by-default shadow mode. It can record what it would have recommended without changing the user’s data or workflow. This creates a controlled path for evaluating the policy before allowing it to influence production behavior.

This architecture separates:

1. Observation: What is happening across the user’s goals and projects?
2. Decision: What action appears most useful?
3. Evidence: Why was that action selected?
4. Execution: Should the system suggest, request approval, or act?
5. Feedback: Did the user accept, reject, or modify the recommendation?

How I built it

Wizzo is built as a full-stack web application using:

• Next.js, React, and TypeScript
• Neon and PostgreSQL
• Vercel and serverless application infrastructure
• LLM APIs for contextual planning and recommendation generation
• Retrieval-augmented generation for grounding responses in product state
• Versioned SQL migrations for evolving the data model
• Structured analytics, audit records, and lifecycle events

The architecture keeps generative output separate from deterministic product behavior. Model responses are validated and translated into structured application state rather than being trusted as unrestricted instructions.

Stable identifiers, feature flags, migration controls, fallback paths, and audit records make it possible to introduce new AI behavior without placing existing user data at unnecessary risk.

Challenges

Making AI useful without making it opaque

It was relatively easy to generate a plan from a prompt. The harder problem was determining when a recommendation was appropriate, what evidence supported it, and whether the system should be allowed to act.

This led to the separation between the language model, the decision policy, and the execution layer.

Maintaining context across long-running work

A meaningful goal may continue for weeks or months. Wizzo needed to preserve dependencies, history, decisions, and user feedback without repeatedly sending the entire workspace to a model.

I addressed this through structured state, targeted retrieval, compact contextual representations, and persistent decision records.

Designing for failure

External model calls, retrieval services, and serverless infrastructure can fail. Wizzo includes bounded fallbacks so core product workflows remain available when an AI or retrieval dependency is unavailable.

Avoiding a text-heavy AI experience

Many AI products place most of the interaction inside a chat window. Wizzo instead presents AI as part of the interface through status changes, recommendations, progress signals, comparisons, and contextual controls.

The next major product phase expands this into a more visual “Living Observatory” interface where users can understand the state of their work without reading long generated responses.

Accomplishments

I am particularly proud of:

• Building and operating the product as a solo founder
• Creating a structured quest and workflow system with dependencies, subtasks, templates, and lifecycle controls
• Shipping analytics and comparison dashboards
• Establishing a production-safe boundary for a future proprietary decision policy
• Implementing shadow evaluation before automated execution
• Replacing fragile infrastructure dependencies with serverless fallback behavior
• Keeping user approval and reversibility central to the AI workflow
• Treating evaluation, privacy, and operational safety as product features rather than post-launch additions

What I learned

The most important lesson was that an AI product is not defined by the model it calls.

The durable product value comes from the surrounding system: state, constraints, evaluation, feedback, interfaces, and the quality of the decisions the software helps a person make.

I also learned that AI reliability is partly a design problem. Users need to understand what the system observed, why it made a recommendation, and what will happen if they approve it.

What’s next

The next phase of Wizzo focuses on:

• Rebuilding the interface around the Living Observatory design system
• Reducing text-heavy interactions in favor of visual state and direct manipulation
• Collecting stronger evaluation evidence from decision-policy shadow runs
• Improving recommendation ranking and confidence calibration
• Expanding user controls for autonomy and approval thresholds
• Developing Wizzo’s proprietary decision policy around real product outcomes
• Making the system more proactive while preserving human authority

Wizzo is an ongoing attempt to build AI that does not simply generate more content. It helps people understand their work, make better decisions, and move forward with clearer evidence.

Built With

• ai-agents
• database-migrations
• feature-flags
• human-in-the-loop
• javascript
• llm-evaluation
• neon
• next.js
• opeanai-api
• postgresql
• product-analytics
• react
• rest-api
• retrieval-augmented-generation
• serverless-functions
• sql
• typescript
• vercel
• workflow-automation