The important work is not building another AI chat experience. It is building the system that turns conversation into durable, measurable work.

Over the last several weeks, I have been building Curious Cirkits as a personal operating system—a kind of Linear for personal life.

It started with two practical use cases: managing a job search and tracking workouts. On the surface, these look like completely different products. A job application has a company, role, résumé, status, interviews, and follow-up actions. A workout has exercises, sets, repetitions, body measurements, goals, and coaching recommendations.

But underneath, they have the same problem.

ChatGPT is very good at helping us think. It can recommend the next job to apply for, tailor a résumé, suggest a workout, or interpret recent progress. But the conversation itself is not a reliable system of record. Decisions become scattered across chats. Recommendations are not always saved. Progress is difficult to measure. The user has to remember what happened and reconstruct the context later.

Conversation is where work is understood. Structure is where work becomes durable.

Curious Cirkits is my attempt to connect the two.

The architecture that emerged

The product is becoming a small set of clearly separated layers.

01ChatGPTThe reasoning and interaction layer. It understands intent, conducts the conversation, uses context, and recommends the most important next action.
02SkillsThe workflow layer. A skill carries the operating knowledge: what to examine, what to ask, what a useful recommendation looks like, and where human judgment is required.
03MCPThe action layer. It gives ChatGPT a controlled interface to read data, update records, save recommendations, and retrieve history.
04SupabaseThe durable, private store for structured records, authentication, ownership, and tenant isolation.
05AppsFocused views into the operating model. They make status and progress visible without reproducing the entire reasoning experience.

This separation has become one of the most important product decisions. The interface can change without rewriting the workflow. The model can improve without changing the data model. A new application can reuse authentication, navigation, permissions, MCP patterns, and recommendation storage instead of starting again.

What changed while building it

The early temptation was to treat Jobs and Workout as individual apps. That quickly created inconsistency. Each page began to develop its own visual language, layout, navigation, and assumptions.

The better approach was to create one configurable app shell.

Jobs and Workout now need to feel like parts of one product: the same navigation, account behavior, responsive layout, visual hierarchy, and interaction rules. The content is different, but the product grammar is shared.

We also made the apps intentionally read-only for normal user interaction. The dashboard is for seeing the current state. ChatGPT is where the user discusses the situation, makes a decision, and asks the agent to take action. An “Open in ChatGPT” link carries the user into a new conversation with a useful prompt already prepared.

That boundary matters. If every app tries to reproduce the full conversational and reasoning experience, the product becomes complicated very quickly. A focused view should remain focused. ChatGPT should do what ChatGPT does well.

Another important change was the treatment of recommendations. A recommendation is not merely text generated for the current response. It is a product object. It should be saved with the relevant app, connected to the supporting context, reviewed later, and replaced when circumstances change.

That is the beginning of proactivity. The system can remember what it recommended, determine whether the action was completed, and surface the next decision. Automation can eventually trigger the review, but the durable recommendation and its status must exist first.

The reusable pattern

The deeper insight is that this architecture is not specific to personal productivity.

Most useful agentic products need the same core loop:

  1. Understand the user’s goal and current context.
  2. Retrieve the relevant structured state.
  3. Apply a workflow and domain knowledge.
  4. Recommend a next action.
  5. Let the user approve, modify, or reject it.
  6. Execute through governed tools.
  7. Save the decision, result, and evidence.
  8. Measure progress and begin the next cycle.

The data and controls change by industry. The loop does not.

In mortgage, an agent could review a loan condition, collect supporting evidence, recommend a resolution, and route the case to an underwriter when accountability requires a person.

In insurance, an agent could assemble a claim, identify missing information, recommend the next investigative action, and preserve the reasoning behind the decision.

In healthcare, an agent could coordinate administrative work while keeping clinical judgment and sensitive decisions within clearly defined human and policy boundaries.

In enterprise operations, an agent could monitor an exception, gather context across systems, recommend a resolution, and execute only the actions allowed by its role.

The domain workflow belongs in skills. The approved capabilities belong in MCP tools. The state and evidence belong in a secure system of record. The focused app shows the work. The model reasons across all of it.

Deterministic foundations, agentic judgment, human accountability

Deterministic where guarantees are required. Agentic where judgment is useful. Human where accountability belongs.

Authentication, tenant isolation, permissions, schemas, audit history, and policy gates should not depend on model interpretation. They need deterministic controls.

Understanding an ambiguous request, synthesizing context, comparing options, and recommending what to do next are areas where an agent can add real value.

High-impact or regulated decisions still need explicit accountability. The system should know when it can act, when it must ask, and when it must escalate.

This is why an agentic product is more than a prompt attached to an API. The surrounding architecture—the harness—is the product. It determines what the agent can see, what it can do, what it must record, and how humans remain in control.

What I am really building

Curious Cirkits currently has Jobs and Workout views, but those are proving grounds rather than the final boundary of the product.

The larger goal is to develop a reusable architecture for products that help people and organizations get work done by tracking it, making decisions, and measuring progress.

Each future module should be easier to add than the previous one. A new app should define its domain objects, views, workflows, MCP actions, and measures—then inherit the common product foundation.

That is also how I want to approach future industry products. Start with a real workflow. Make the state visible. Separate reasoning from execution. Preserve every important decision. Build controls into the architecture. Then create a learning loop that improves both the agent and the process.

The most valuable agentic systems will not be the ones that talk the most. They will be the ones that reliably move work forward—and can show what happened, why it happened, and what should happen next.

That is the architecture Curious Cirkits is helping me build.

Build for the outcome. Preserve the decision. Measure the progress.