Build your own private AI adviser notebook
A customisable ChatGPT Site brief

Template, not a finished Site or deployable application. Created by Elina Halonen as a public companion to the Susie Myerson / Ten Percent Desk experiment, Building with AI (https://elinahalonen.com/building-with-ai/susie-myerson.html).

This document is deliberately not the specification for Elina's private notebook. It contains no personal dossier, real contacts, source credentials, existing Site IDs or private notes. It uses the design pattern behind Ten Percent Desk so you can develop your own. Change the character, categories, information model, voice, visual direction and permissions to fit your situation.

Quick start

1. Start a new ChatGPT Work conversation with Sites available. Building the website is a development task; once it is built, conversational use of your character may work better in an ordinary Chat conversation.
2. Upload this file or paste the Builder prompt below.
3. Ask ChatGPT to customise the specification with you before building. Answer only the questions that apply; it should not assume your notebook has the same purpose as Susie's.
4. Have it create and test the actual private Site, not a mock-up or a ZIP of static files. Inspect the privacy settings before putting real information into it.
5. Test the real agent-to-Site connection from your normal ChatGPT conversation. Creating a Site does not necessarily connect your existing assistant to it.

-------------------------------------------------

Builder prompt: customise, build and verify my AI adviser's private notebook

I want a functional, private ChatGPT Site that acts as the working notebook of an AI adviser, creative partner, researcher or other specialised assistant. It should make the assistant's useful observations durable, searchable, contestable and revisable.

Do not build immediately from the example design. First help me customise it for my own assistant, work and preferences. Do not assume I want a talent agent, vintage office, business pipeline or the exact categories described later. Those are examples, not requirements.

1. Customise the design with me

First inspect any character instructions, notes, screenshot, existing prototype or Site I provide. Reuse an existing assistant when possible rather than creating a duplicate.

If the answers aren't already in my materials, ask me a few concise questions covering:

1. Who is this for? The assistant's name, role, relationship to me and what it ought to notice, advise on or remember.
2. What belongs in the notebook? A handful of recurring records, examples of worthwhile entries and what definitely doesn't belong. Suggest categories that suit those examples, rather than imposing the sample categories.
3. What should the human and AI each do? Who can create, propose, approve, edit, reply, revise or archive records? Do I already have an assistant/plugin that needs connecting?
4. How should it feel? Any visual references, tone, accessibility requirements and devices I expect to use. Functional usability comes before decoration.
5. What privacy or integration constraints matter? Whether records include sensitive personal information, confidential work, third-party data, existing research libraries or other systems.

Do not require me to answer every possible design question before proceeding. If an optional detail is missing, suggest an editable default and tell me what you assumed. Confirm consequential choices such as sharing private data, public accessibility, deletion or creating a second agent.

Then present a compact agreed configuration, in plain language: purpose, audience, working views, permissions, visual direction, available integrations and what success would look like. Build from that configuration, not from unaltered sample text.

2. What kind of notebook to build

This is the assistant's working book, not an all-purpose second brain, generic CRM, generic task tracker or archive of every chat.

An entry should preserve a worthwhile judgement, hypothesis, observation, proposition, warning, disagreement, relationship context, test or lesson, depending on the assistant's actual role.

The assistant should have room to develop a point of view different from mine. I should be able to respond, dispute or annotate without rewriting the assistant's original statement. The original thought, subsequent corrections and actual outcomes must remain distinguishable.

Use a clear distinction between:
- Observed fact, with source and date when material.
- Assistant's interpretation or proposal, explicitly attributed.
- My own statement or decision, not silently attributed to the agent.
- Outside evidence, with a reference and appropriate uncertainty.
- Observed outcome, which cannot be invented to make the system look active.

Keep notes selective. A useful notebook does not have to capture every exchange.

3. Information architecture: adapt these examples

The Ten Percent Desk example used the following nine editorial views. These are optional starting points, not nine compulsory fields or a prescribed layout:

| Example view | Possible purpose |
| --- | --- |
| The Client / The User | The adviser's working understanding of the person and relevant context |
| Opportunities | Possibilities or hypotheses worth considering |
| Pitches & Positioning | Ways of describing, presenting or proposing work |
| People & Contacts | Important real relationships and conversations |
| Follow-ups | Specific questions or conversations worth revisiting |
| The Reference File | External examples, organisations or models worth studying |
| Warnings & Advice | An argued risk or recommendation |
| Conversations & Arguments | Differing judgements, unresolved questions and responses |
| Lessons & Outcomes | What actually happened, and what can be learned from it |

Replace, rename, combine or delete these views. An editorial view is not necessarily a mutually exclusive record type. A note may appear in more than one relevant view.

For navigation, a workable starting point might include:
- Desk/Home: overview and direct paths to useful records; no fabricated activity.
- Notebook: browsable records, search, filters and category views.
- Incoming proposals: notes submitted by the AI for human review.
- Principles/About: how this particular adviser works, with the privacy and provenance rules.

Choose a structure based on the customised content, not a decorative metaphor.

4. Minimum viable record and behaviour

Each accepted record needs an actual durable identifier, a title, body, relevant views or categories, authorship, creation/update time and a status. Extend it with only the fields this notebook genuinely needs, for example:

- A grounded source or conversation reference.
- An attributed hypothesis or recommendation.
- Supporting evidence and relevant uncertainty.
- A response or disagreement from the owner.
- A proposed next test, clearly separate from an agreed action.
- A link to another actual record.
- History of later revisions, without erasing the original.

Status labels should be tailored to the notebook. Open, Investigating, Testing, Parked, Closed are examples, not evidence of demand, completion or success. Closed may simply mean no further action.

The working Site should let an authenticated owner browse, search, filter, open, create and edit records; reply, inspect revisions and change status where implemented. Keep the interface simple enough that adding a note doesn't feel like completing a funding application.

If full editing or revision history is not technically supported, build the smallest reliable alternative and state exactly what is missing. Do not represent an inert mock-up as functional software.

5. AI-to-Site connection and review workflow

Inspect the actual Sites capabilities and any existing assistant/plugin before committing to an integration architecture. The Site may have its own connector or companion plugin. Do not automatically create a duplicate assistant, assume the first plugin can see the Site, or invent API actions.

An example bounded integration is:
- Search notes: retrieve accepted records relevant to the conversation.
- Read note: retrieve an existing record with its replies, provenance and revision history.
- Propose note: submit a candidate record to a private Incoming proposals queue.

When the user asks the assistant to capture something, it should check for a duplicate if relevant, draft an attributed record and propose it. It must report the outcome accurately. Proposed means waiting for review; it does not mean accepted into the notebook. The authenticated owner can accept or reject it in the Site. If the connector exposes a verified pending-proposal list and approval action, the owner may also explicitly authorise acceptance in a ChatGPT conversation: one named proposal, several specified IDs, or all proposals pending at that moment. The assistant should inspect the IDs and contents first, then report each result. A proposal's existence, or the assistant's own suggestion, is never permission to approve it. Bulk approval must capture the pending IDs before writing so later arrivals are excluded. Repeating an approval must not duplicate a record. Preserve the proposal's categories (including multiple views), evidence, provenance, attribution and origin history. Editing or deleting accepted records requires separately verified functionality.

Do not automatically write every observation. Avoid unrequested external messages, fabricated contact history or changes to other connected systems. If the intended action isn't available, provide a draft for manual entry and say so.

Tool names and supported arguments depend on the Site actually built. Discover and test them; don't copy the private Ten Percent Office's internal tool names into a new project.

6. Privacy and persistence

This must be a private notebook with appropriately protected storage, authenticated access and scoped permissions. Don't rely on an obscure URL, browser-local storage, or a public static JSON file when private data is involved.

Keep real notes, private documents, research-library contents, customer records and third-party contact details out of the public repository and any sample prompt package.

Support export and backup where feasible. Preserve a means to recover records and the history behind them. Before deploying, verify whether the Site is truly private and who can read, write and share its records.

No fake integrations, automatic email sending, autonomous outreach, or invisible access to unrelated accounts.

7. Visual design

Ask me for a direction or use my supplied visual reference.

The original example borrowed from a 1960s talent office, but do not assume your notebook should look like that. A scientific field notebook, editorial research library, studio archive, modern application or another theme might be better.

Use original or appropriately licensed assets. Keep text legible and mobile friendly, with accessible contrast, keyboard navigation and meaningful controls. Make the atmosphere enjoyable without turning functional information into a novelty prop. Never reproduce copyrighted television stills or dialogue as interface assets.

8. Build an actual Site, then test it

Use Work and Sites to build the customised private application with durable storage. Test all visible controls. Show a working preview and explain which parts have been verified.

Acceptance checks:
1. A real note survives refresh, a new session and an authenticated second device.
2. Search and filters return the correct records; empty results are honest.
3. A human reply and subsequent revision remain attributed and inspectable.
4. An assistant can search and read an accepted record if that connection exists and has been tested from ChatGPT.
5. A proposed record appears in Incoming proposals without silently becoming an accepted record, if proposal support is implemented.
6. Unauthenticated users cannot read or alter private notes.
7. If conversational approval is implemented, the authenticated owner can list pending IDs, accept one or several explicit IDs, and approve a snapshot of all pending proposals. Verify the accepted records are searchable with categories and metadata intact; retrying approval is safe, and unauthenticated approval is denied. Test with isolated records, without leaving unwanted examples in the real notebook.
8. A saved note's ID, status and actual outcome are reported truthfully.
9. The site works on desktop and mobile, and no decorative controls pretend to do something they can't.

If any requirement is unsupported, provide a useful partial implementation and a truthful, prioritised description of the limitation. Do not declare a Site or connector finished based on an image, local prototype or assumed tool availability.

9. Deliverables and handover

Give me:
- The private Site and clear access instructions.
- A short guide to its working views, records, search, replies, proposals and status controls.
- Which ChatGPT assistant it is connected to, the tools actually available, and what permissions they have.
- A brief record of design decisions, tests run, known limitations and how to update the Site later.
- The current source or an appropriate export where supported, without exposing private note contents.

Begin by examining what I've supplied and helping me customise this template. Do not immediately produce a themed mock-up or pretend that a Site is functional before testing it.

-------------------------------------------------

Using the finished notebook

Once the Site is built, return to an ordinary ChatGPT Chat conversation with your specialised character for exploratory interactions. In the original author's informal experience, characters have felt more natural there than in Work mode, though this isn't a controlled comparison and the cause isn't established.

You may use Work to build or substantially modify the Site. The assistant's live read, proposal and optional approval capabilities still require a verified, authorised connector in the relevant conversation. A private Site and a private conversational character are distinct pieces of the system until actually integrated.

Adapt this template freely. It's a starting point for designing a relationship and a working record, not a claim that every ChatGPT account or Site environment offers the same functionality.