I built an AI workspace.
Then I needed a way to run it.

In my previous article, I wrote about using AI to help turn my experience into a business: shaping the offer, building the website and developing an editorial agent.

As that work expanded, so did the environment around it.

I use chats to explore ideas and challenge my thinking. Projects hold context around different areas of the business. Custom GPTs support recurring work. Codex helps me build and change the website and internal tools. Plugins and connectors bring documents, email and other applications into those workflows.

Alongside these, I’ve built a series of agents to help with identifying potential leads, maintaining CRM records, developing and publishing content, and managing invoicing.

These pieces have different jobs. Some help me think. Some produce something I can review. Others prepare or carry out actions in another application, with different levels of human involvement.

Together, they generate a growing body of work.

And I needed a better way to keep track of it.

The work moves. The context doesn’t always follow.

An idea explored in a chat becomes an editorial draft. Work in Codex becomes a website change. Lead research becomes a CRM record. An approved article moves into publication.

Each step leaves something behind: a document, code, a record, a decision or a task.

Some of that stays inside a project or conversation. Some lives in a connected application. Sometimes an earlier version remains perfectly easy to find while the current one takes more effort.

I began running into questions that had little to do with generating the next output.

Where is the version I approved?

Did we decide to develop this idea, or only discuss it?

Has that action actually happened?

What needs my attention before the work can move forward?

I could open the relevant chats, projects and tools to investigate. But reconstructing the state of the work was becoming work in itself.

A useful conversation is not always a reliable record

A working conversation contains possibilities, objections, rejected directions and decisions. It can also contain intentions that sound very close to completed actions.

“Let’s do it” might mean develop the idea.

“Looks good” might mean the draft is ready for another check.

A date might be a suggestion, an agreed target or a confirmed booking in another system.

Those differences can be clear in the moment. They become harder to recover when you return later, particularly after the work has continued somewhere else.

Asking an agent to summarise helps recover context. But a summary can faithfully describe an earlier plan that is no longer current.

I needed a place to return to without rebuilding the whole story.

That was the job for the dashboard

I started building a dashboard to bring together a view of projects, tasks and editorial work, with links back to the relevant material.

For content, I wanted to distinguish what we were actively developing from what was planned, sitting in the backlog or already published.

An idea I might explore someday should not compete for attention with an article that needs reviewing this week.

I also wanted the dashboard to help me find the work without creating another copy of everything.

Editorial texts could remain in the editorial document. The website code could remain with the website. The dashboard could show the current state and point me to the right place.

The practical goal was simple: open it, understand where things stand and decide what to do next.

Then I had to learn what made the dashboard trustworthy

Building that view did not automatically make it dependable.

One recent publication made this particularly clear.

The website article was live. Its connecting LinkedIn post had gone through scheduling, but an early check of the queue showed no scheduled posts. That left the LinkedIn publication uncertain.

Later, the public post was verified and the dashboard was updated.

When I asked about it again, the agent repeated the earlier uncertainty. It told me the publication still wasn’t confirmed.

The dashboard already held the newer answer.

We checked the public post again. It was there, with the image, article link and hashtags.

The problem was no longer the absence of a record. The agent had answered without consulting the current one.

That changed how I thought about the dashboard.

It needed to be part of the working process, including how agents checked their answers.

What I’m learning to make explicit

I’m finding that a few distinctions need to survive every handoff between a chat, project, agent and application.

A proposal and a decision. An interesting direction should remain distinguishable from something I have committed to doing.

Preparation and execution. A prepared invoice is different from a sent invoice. A publication target is different from a post saved in a native scheduler.

A reported success and a verified result. When an action matters, we need to check the place where it happened. A date passing does not prove publication.

An earlier account and the current record. Before answering a status question, the agent needs to read the information we have agreed to maintain.

There is also a maintenance cost. If a record has changed, related tasks and calendar summaries may need reconciling. Otherwise, each surface can offer a plausible but different account of the same work.

I’m still testing how much of that can be handled reliably by agents and where I need to remain involved.

Start with the questions you keep asking

If I were starting again, I would begin with the questions I repeatedly struggle to answer.

Where is it?

Which version counts?

What did we decide?

What actually happened?

What needs me now?

Then I would decide where each answer belongs and how it should be updated.

That gives the dashboard a concrete purpose. It also helps decide what does not need to be there.

For JFG·NEXT, the dashboard has given me a clearer place to return to. The mistakes have helped me understand what is required to keep that place useful.

From my workspace to a team’s way of working

This experience is also shaping a broader question for JFG·NEXT.

If coordinating my own projects, chats and agents requires explicit records and checks, what does a marketing team need when several people and tools are working across messaging, audiences, content and customer information?

That is where I want to explore the idea of a Marketing OS: the shared knowledge, responsibilities and workflows that help a team work coherently.

I haven’t implemented that full model in my own business. The dashboard is one practical experience informing the questions I would bring to it.

For now, there is a useful place to begin:

Close your AI tools for a moment. Could you still find what was decided, what was delivered and what needs to happen next?