Guillaume Lab

A personal AI environment that preserves useful context and turns conversations into human-approved decisions and everyday actions.

Comment

Guillaume Lab — From a forgotten conversation to continuous context

Inspiration

Guillaume Lab did not begin with a desire to build an application. It began with a very simple frustration that I often encountered while using ChatGPT.

I could have a rich conversation, develop an idea, make a decision or understand a subject in depth. Yet a few days or weeks later, part of that context was gone. I had to search for an old conversation, explain again what had already been said, or reconstruct reasoning that we had already established.

So my first question was not: “How can I build an application?”

It was: “How can useful context survive a conversation and be found naturally when I need it?”

Little by little, that question became much broader. I realised that it was not only a memory problem. It was also a mental-load problem. We use many tools, each with its own information, interfaces and rules. I wanted to create an environment where AI could help me find the right context at the right time, without forcing me to think constantly about which application I was using.

I am not a trained developer. I am a physiotherapist and an entrepreneur. I bring an overall vision, very concrete needs from my daily life and human validation. ChatGPT helps me clarify my ideas, and Codex has gradually made it possible to turn them into software that I can actually use. Code was never the starting point. It became the consequence of a need that had been understood and a solution that I wanted to test in real life.

What existed before Build Week

Before Build Week, Guillaume Lab already existed as a local-first personal AI environment that I had been developing progressively for several months.

Jarvis is the main coordinator. It maintains the general context, understands intent and connects specialised agents with different working spaces.

Flux receives documents and helps turn them into useful, structured and correctly classified information.

Thinking Room contains persistent workspaces. A workspace can gather conversations, documents, emails, sources, decisions, assumptions and unfinished ideas around one subject. It can later be reopened, summarised or used as the basis for a new analysis or output.

Ulysse focuses on finance, professional activity, investments and decision support.

Radius is a specialised professional assistant, with separate access boundaries for medical work and personal physical data.

Cooper is the companion designed to make the Lab accessible in everyday life, on the move and, eventually, through a physical object.

The entire Lab was not built during Build Week. It was the environment in which this week’s work took place. The goal was not to recreate everything, but to move an existing, already-used architecture forward in a meaningful way.

What really triggered this week

This is probably the most important part of the story: when we started developing these capabilities, I did not yet know that I would enter the competition.

For a long time, I had wanted to make the financial part of the Lab genuinely useful. Previous models could produce interesting analyses, but they were sometimes too general or too fragile to guide concrete decisions. My forecasts, expenses and bank statements existed, but I could not yet obtain a sufficiently coherent view to use every day.

With ChatGPT Work and GPT-5.6, something changed. For the first time, I could revisit my financial forecasts, provide several bank statements and progressively analyse everything as one continuous problem.

We compared forecasts with actual spending, separated recurring expenses from investments, analysed private and professional finances independently, and brought out figures that I could genuinely understand and use.

I then thought: this understanding should not remain locked inside one conversation. It should become a living part of the Lab.

That was the trigger for the work presented during Build Week. The competition came afterwards. The project was not invented to answer a brief: it came from a real need, and the new capabilities of ChatGPT Work, Codex and GPT-5.6 finally made it practical.

What we built during OpenAI Build Week

1. The Ulysse financial dashboard

The first step was to build and connect a real financial dashboard around this new analytical capability.

Ulysse now brings together private finances, company finances, investments, patient activity, forecasts, actual spending, reserves and alerts.

The goal was not simply to display figures. I wanted to open Ulysse and quickly understand whether the situation was balanced, which categories were moving away from the forecast and where a decision was becoming necessary.

We also created detailed views behind the main cards so that income, expenses and each budget category can be inspected when a more precise analysis is needed.

2. The Ulysse decision cockpit

Once the dashboard became useful, a new limitation appeared: seeing the figures was not enough. We also needed a real place to understand them, discuss them and prepare decisions.

We therefore completely redesigned the Ulysse cockpit as a more immersive, conversational and voice-enabled environment. Ulysse can use the available financial context, explain a situation, compare several scenarios and retain the decisions that I validate.

GPT-5.6 is used in this environment to analyse a limited and structured cross-domain context. It distinguishes facts from assumptions, identifies missing information and prepares possible options. Those options remain subject to human approval.

Important alerts identified by Ulysse can also surface discreetly in Jarvis’s daily dashboard. I did not want to monitor every interface constantly: important information should be able to come to me when it genuinely deserves my attention.

3. Maison: turning an alert into a concrete action

While analysing the household budget, we identified groceries as one of the categories that needed better monitoring.

An alert saying that a budget may be exceeded is useful, but it does not solve anything on its own. I wanted to move from analysis to a concrete adjustment in everyday life.

That led to Maison. Maison connects the grocery budget with menus, recipes, required products, available stock and preparation of an order.

Instead of receiving only a warning, I can work with the Lab on a realistic correction for the following weeks. Finance no longer remains an abstract dashboard: it can lead to a concrete, measurable action that is still approved by the user.

This was an important moment in the project because it showed that several domains could be connected without becoming confused. A financial analysis could lead to a household decision while each tool kept its own role.

4. Cooper Mobile: capturing expenses when they happen

Another limitation then appeared. Waiting for the bank statement at the end of the month does not make it possible to manage a budget properly during the month.

For the monitoring to remain useful, an expense must be declared when it happens.

We therefore created and consolidated Cooper Mobile, a real Android application connected to the Lab through a secure gateway and dedicated permissions.

An expense can be announced from the phone or by voice. Its amount becomes immediately useful for daily guidance and the Maison budget, while remaining clearly provisional until it is reconciled with the real banking document.

Cooper Mobile is not limited to finance. It can also place an idea in the Lab, create or summarise a workspace, find or send a document, request advice or research, and control selected phone actions such as playing music or preparing a call.

It is gradually becoming the mobile access point to the Lab in everyday life. The goal is not to give the phone indiscriminate access to the whole system, but to let it use only the capabilities that are authorised and useful in the current context.

5. Flux and reconciliation with accounting reality

Daily declarations are useful, but they cannot replace real records and source data.

We therefore strengthened Flux so that an invoice, photograph or bank statement can arrive, be understood and receive a proposed classification. The user can inspect the document, validate the proposal and send the information to the appropriate part of the Lab.

At the end of the month, the bank statement reconciles the expenses that were declared provisionally. Any differences are identified, the Ulysse dashboard is updated and the figures for the closed month become the accounting reference.

We had to be very precise here: a declared expense must affect the current budget immediately, but it must not be counted a second time when the bank statement arrives. The distinction between declared, provisional, reconciled and validated is therefore part of the actual behaviour, not only the interface.

6. Voice, earbuds and the future Cooper Prism

We also validated the complete mobile voice chain with Bluetooth earbuds: a physical gesture, a locked phone, the microphone, Cooper Mobile, the secure gateway, authorised Lab access and a spoken response.

This chain allowed us to prepare the next physical step: the Cooper Prism.

The Prism is designed as a portable remote for the Lab. The custom hardware is still in the design phase, but during the week we worked on its components, target dimensions and main usage contexts.

Worn as a magnetic pendant or integrated into a brooch, it could make it possible to speak to Cooper while the phone remains in a pocket. It could also ask the Lab to display a document or response on the phone, a television or another available screen.

Docked at a desk, the same object could activate the working environment and the appropriate access. Placed in an audio base in a room such as the kitchen, it could use the capabilities of that environment, including speakers and music.

We are not presenting the physical object as finished. What already works is the mobile, voice, gateway and Lab-response chain that the Prism will reuse. This distinction matters to me: I want to show what genuinely exists while explaining clearly where we are going.

How we built it with ChatGPT Work, Codex and GPT-5.6

The most important change was not ultimately the speed of development. It was the way the project itself could be designed.

Most new capabilities did not begin with code. They began with a discussion. I would arrive with an idea, an intuition or a very concrete need:

“I would like the Lab to do this. Is it realistic? How could we integrate it without breaking the existing architecture? Which parts could we reuse? Does something in the Lab already address part of the problem?”

ChatGPT Work would first analyze the situation, inspect the repository and suggest several architectural directions. This first step felt more like an audit than code generation.

Previously, I clarified an idea in ChatGPT, asked it to prepare a prompt, transferred that prompt to Codex and still copied some changes into the terminal myself. Each handoff could lose part of the context. With ChatGPT Work, the vision, repository access, audit, implementation, tests, visual inspection and my feedback remain inside the same discussion and the same working environment. I no longer need to reconstruct the logic of the work at every stage.

We would then discuss the proposals. I often brought the problem back into the wider vision of the Lab. I could point out that a capability already existed, that another had been developed several months earlier, that the two could be connected, or that the same logic had to remain coherent across several parts of the project:

“This part already exists.”

“This capability could be connected to that one.”

“Be careful, we need to preserve this logic.”

“This behavior will also need to work in another context.”

This conversation gradually aligned the technical solution with the overall direction instead of treating each capability in isolation. Once that direction was approved, we moved into implementation.

The conversation did not stop during development. I could follow progress, correct an interpretation, restate a constraint, point out a consequence that appeared as the work evolved, or ask it to consider another part of the Lab before continuing. At other times, I could let ChatGPT Work autonomously conduct a clearly bounded workstream, then return later to analyze the result, test it and decide what should happen next.

This alternation between direct supervision and controlled autonomy gradually became a natural way to work. Several design conversations could progress in parallel on different aspects of the project, while a single controlled path modified the shared code in order to preserve coherence.

The most striking evolution, however, came with GPT-5.6. With previous models, I generally had to break a problem down into many very precise steps. I had to describe almost every screen, behavior and sometimes every interface element.

With GPT-5.6, I observed a meaningful change: the model seems to understand the purpose of a workstream much more quickly. It does not only process an isolated task; it tries to understand the overall goal before proposing a solution. It can therefore suggest coherent elements that I did not explicitly request, simply because they fit the wider logic.

I saw this especially while designing the Ulysse cockpit. Instead of changing only the elements described in my instructions, GPT-5.6 proposed a more complete and coherent organization, added elements that naturally belonged in the product, and anticipated connections between several parts of the Lab without my explicitly requesting them.

I also found that I could entrust it with a genuine workstream rather than a single feature. When it understands the purpose well enough and has the necessary context, it can connect several existing components, anticipate some dependencies and evolve an entire chain rather than one isolated component.

This does not replace the human role. On the contrary. I still define the vision, connect the ideas, arbitrate between choices, test the result and approve every important evolution. Codex inspects the existing system, implements changes, runs test benches, checks the real interfaces and fixes regressions, but decisions that shape the product remain human.

I now spend much less time explaining every implementation detail and much more time thinking about the product itself. The conversation has become a genuine design space. At the beginning of Guillaume Lab, I sometimes completely broke the project while trying to change the code myself. I no longer approach development that way. My role has become that of the designer: I define the vision, guide the choices and validate the result.

I therefore feel more like I am steering a development workshop than occasionally requesting pieces of generated code. The most important difference is not ultimately that AI writes more code. It is that understanding the project has become part of the development process itself. That shared understanding lets us discuss intent, user experience and overall coherence more often than every implementation detail.

The production loop became: human intent → discussion → audit and proposals → alignment with the overall vision → approved direction → testable implementation → tests → real use → feedback → correction → human approval.

This collaboration also produced its own engineering workshop: more than one hundred focused test benches in the main Lab, behavioral contracts, a central model registry, privacy audits, backups and an agent factory governed by structured blueprints. The acceleration therefore remains framed by a method designed to preserve coherence, reversibility and human control.

The result

At the end of the week:

  • Cooper Mobile works on Android.
  • Ulysse compares real data with forecasts and explains important deviations.
  • Its cockpit supports contextual discussion and GPT-5.6 analysis.
  • Maison connects a grocery budget with menus, recipes, stock and preparation of an order.
  • Flux analyses and classifies financial documents before reconciliation.
  • Important Ulysse alerts can surface in Jarvis.
  • The software and mobile chain intended for the future Prism has been tested.

These are not independent demonstrations. They form one loop:

expense → Cooper Mobile → Ulysse → Jarvis → Maison → human-approved action → Flux → reconciliation → durable context.

What interests me in this loop is not only that it connects several tools. It is that one conversation can accompany intention, understanding and action without forcing the user to reconstruct the context at every step.

The public demonstration

The real Guillaume Lab contains personal information and many capabilities that are outside the scope of Build Week.

To let the judges test the project without exposing the private Lab, we built an isolated public demonstration using fictional people, accounts, documents and amounts. It deliberately presents only the elements created or substantially reworked during the week.

The demonstration has no network route or credentials that would allow it to access the private Lab. Each visitor receives an isolated session that can be reset.

The technical repository describes the architecture, setup procedure, security boundaries, use of Codex and GPT-5.6 and the available test evidence.

The demonstration is therefore not the project itself. It is a safe and reproducible way for the judges to experience the loop that we built.

Challenges

The main challenge was not creating more screens.

We had to preserve the meaning of information as it moved from a conversation to a mobile declaration, then to a budget, a document and finally an accounting result.

We also had to distinguish clearly between four things: what the user says, what the AI infers, what it proposes and what has actually been approved.

The financial flow added a very practical difficulty: a declared expense must change the current budget immediately, but it must not be counted twice when the bank statement arrives.

Finally, we had to allow genuine use by the judges while protecting the real Lab and personal data. This separation between the private environment and the public demonstration became an integral part of the work.

What I learned

I learned that the value of a personal AI does not come from the number of features visible on screen.

It comes mainly from finding the right amount of context, explaining what is known and what is assumed, and then helping the user move from understanding to action without taking away control.

I also understood that an assistant should not constantly propose actions. There are times when I simply want to discuss an idea. At other times I want to explore several possibilities. Only later do I sometimes want to build or change something.

Making interfaces disappear does not mean removing control. It means making them appear at the right moment and in the right context.

Finally, AI-assisted development does not remove the human role. In my experience, it shifts that role towards intention, overall coherence, arbitration, real-life testing, judgement and responsibility.

What is next

The Lab is still in development.

The next steps are to improve long-term decision tracking, automate more of the arrival and processing of documents, and make this kind of personal environment deployable for other people without losing its local-first, governed and personal approach.

The Cooper Prism still has to move from the current design and component-selection phase to a first physical prototype.

The overall goal remains the same as it was at the beginning: allow useful context to last, reduce mental load and create an AI companion that is present when needed without becoming intrusive.

At first, I simply wanted to stop losing the context of a conversation. Today, Guillaume Lab is gradually connecting conversations, documents, decisions and everyday actions. Build Week is not the end of this project. It is the moment when the new capabilities of ChatGPT Work, Codex and GPT-5.6 allowed me to turn a long-standing idea into something that I actually use.

Built With

Share this project:

Updates