Markdown is a killer substrate for a personal agent. The moment the agent serves other people, context stops being a folder and becomes a governed retrieval and memory layer.
A local LLM wiki works because the trust boundary is small: one user, one machine, one note graph, one tolerance for mess. A production agent crosses a different line. It needs governed access to business data, scoped user memory, access rules, retrieval controls, and evidence that survives the demo.
Markdown is not broken. It is just being asked to do a job it was never hired for.
Second brain
One user
Markdown wiki
Local notes
Context plane
The line is not markdown versus database. The line is personal context versus governed production context.
Reader confidence starts with source posture
This artifact is derived from a public Cole Medin video and an out-of-band source packet for R-5_2nsF_ZM. The video is used as the narrative source and teaching seed. Redis Iris is treated as the demonstration substrate, not as an endorsed architecture requirement.
Current Redis documentation is used to verify Redis Iris terminology and capability framing. The Redis demo repo is used to verify the implementation posture and preview caveat.
Raw transcript, subtitle files, packet zip, local staging paths, screenshots, and media are not published.
Artifact metadata
Primary source
Public YouTube source packet for R-5_2nsF_ZM: Cole Medin, “I Love the Karpathy LLM Wiki but it Doesn't Scale. Here's What Does.”
Source role
Narrative source and teaching prompt. Not a neutral benchmark. Not vendor-independent market analysis.
Verification sources
Redis official docs and public demo repo.
Caveat
The source includes Redis partnership/vendor framing. The artifact keeps the architecture pattern and strips the sales gravity.
Exclusions
No raw transcript. No unverified scale claims. No Redis-as-best-platform conclusion. No implementation tutorial.
Public links
- Primary source: https://www.youtube.com/watch?v=R-5_2nsF_ZM
- Redis Iris docs: https://redis.io/docs/latest/develop/ai/context-engine/
- Demo repo: https://github.com/coleam00/redis-iris-agent
Current verification notes
Redis Iris is shown here as capability framing and demonstration substrate only. Context Retriever and Agent Memory carry a preview and proof-of-concept caveat in the public demo repo.
Field Brief and Deep Architecture View
Two entry points for the same artifact: fast operational read first, full architecture argument second.
The short version: your folder is not the product boundary
A personal second brain is one of the best AI patterns we have right now. Markdown is readable. Git-friendly. Portable. Easy to edit. Easy for agents to crawl. Close to the human doing the work. That is why the Karpathy-style LLM wiki idea works.
For one person, it is almost perfect.
Then someone tries to ship it to other people.
That is where the architecture changes. Not a little. Completely.
A personal agent can live in your local mess because you own the mess. A production agent does not get that privilege. It has users. Roles. Live data. Different histories. Permissions. Memory across sessions. Failure modes. Audit questions. Things humans traditionally ignore until the demo gets promoted and starts biting ankles.
The production move is not “make the markdown folder bigger.” The production move is to build a context plane.
What works
Markdown is excellent for personal memory because it is simple, inspectable, and owner-controlled.
What breaks
The second the agent serves other people, the folder stops being a memory surface and starts pretending to be a system boundary.
What replaces it
A governed context plane: structured access to business data, scoped user memory, generated tools, access control, and retrieval discipline.
What Redis shows
Redis Iris is useful as a current demo substrate for this pattern. It is not the thesis. The thesis is the architecture boundary.
What to remember
A second brain is a personal operating surface. A production context plane is a shared system boundary.
The argument before the diagram
Markdown is not the villain.
For a personal AI agent, markdown may be the cleanest context substrate you can build. It is readable. It is editable. It sits in a folder you control. You can version it, back it up, search it, index it, and hand it to an agent without creating a platform team, a database migration, a service mesh, and six new reasons to hate your calendar.
That simplicity is the point.
A local LLM wiki works because the trust boundary is small. One user. One machine. One working context. One person who understands the notes well enough to forgive the gaps.
That is why the pattern feels so good. It lets the agent operate over a living body of personal context without turning the whole thing into enterprise architecture theater.
But the moment you ship the agent to other people, the premise changes.
Now the agent has to know who is asking. It has to know what they are allowed to see. It has to retrieve current business data without directly rummaging through raw systems. It has to remember different users differently. It has to separate session state from durable memory. It has to leave enough evidence behind that someone can explain what happened later.
That is not a markdown problem anymore.
That is architecture.
The useful split is simple: business context and user memory.
Business context is the operational world. Customers, orders, products, policies, tickets, shipments, entitlements, records, status, and current state. It changes. It has structure. It has access rules. It should be exposed through defined tools and governed retrieval, not dumped into a prompt like a junk drawer with embeddings.
User memory is different. It is the user’s history, preferences, prior interactions, working session, durable facts, and learned patterns. It needs scope. It needs lifecycle rules. It needs retrieval. It needs inspection. It must not quietly merge into business truth just because the model sounded confident.
A personal second brain can blur those lines because the owner is the system. A production agent cannot. In production, the lines are the system.
That is why the Redis example is useful. Redis currently describes Iris as a fully managed context engine for AI agents that covers persistent memory, semantic caching, governed data access, and live data sync on Redis Cloud. Current Redis docs list four Iris services: LangCache, Agent Memory, Context Retriever, and Data Integration.
The important idea is not “use Redis.” The important idea is that production agents need a governed context plane. Redis describes Context Retriever as schema-first governed access where agents call generated tools instead of directly accessing the database, with agent keys, access tags, and explicitly defined tools.
Agent Memory shows the other half of the pattern. Redis describes a two-tier memory model: short-term session memory with TTL-based expiration, and long-term memory storing extracted preferences and learned patterns with vector embeddings for semantic retrieval.
The demo repo reinforces the split cleanly: Context Retriever is the data, Agent Memory is who the user is, and together they form a context layer across sessions and users. It also says both Context Retriever and Agent Memory are in preview and the repo is a proof of concept, not a production template. That caveat matters because architecture without caveats is just marketing with cleaner typography.
So the rule is not complicated.
Use markdown when the agent is personal, local, owner-operated, and safe to keep simple.
Use a context plane when the agent serves other people, touches live data, remembers users across sessions, applies permission boundaries, or needs evidence that can survive review.
The difference is not sophistication.
The difference is responsibility.
Your second brain is allowed to be a folder. Your production agent is not.
Business context and user memory are not the same job
A personal second brain can keep everything in one pile because the owner understands the pile. Production systems do not get that luxury. They need separate surfaces for operational truth and user-specific memory.
Question answered
What is true in the operating system right now?
Examples
Customers, orders, shipments, products, tickets, policies, entitlements, records, status, and current state.
Required properties
Fresh enough, structured, permissioned, tool-accessed, inspectable, and not exposed as raw system rummaging.
A production agent should call defined tools, retrieve scoped memory, apply permissions, and leave evidence.
Question answered
What should this agent remember about this user?
Examples
Session state, preferences, prior interactions, durable user facts, learned patterns, and recall hooks.
Required properties
Scoped to user, separable from business truth, retrievable, lifecycle-managed, and safe to update.
The test is simple: who owns the blast radius?
Do not promote a personal memory pattern into a production boundary because it demoed well on your laptop. That is how prototypes grow teeth.
Claim posture matters because demos are not architecture
Visual prompt suite
Each visual concept includes a Mainline White prompt and a Dark Expressive prompt. The prompts are complete, copyable, and designed for production visual exploration.
Prompt 01: Personal Wiki vs Production Context PlaneMainline White + Dark Expressive
Mainline White Prompt
PRIMARY GOAL
Create a premium 16:9 teaching graphic that explains the central thesis: a personal markdown second brain works inside a small trust boundary, but a production agent needs a governed context plane. The visual must show the architectural threshold clearly. It must not be a Redis product graphic.
AUDIENCE
AI architects, platform owners, engineering leaders, product-minded technologists, governance teams, and builders moving from personal agent workflows into production agent systems.
FORMAT AND ASPECT RATIO
Single static editorial infographic, 16:9 landscape. Suitable for a SharePlane hero section, architecture briefing, or conference-style teaching slide. No animation.
VISUAL SYSTEM
Use the Mainline White visual system:
* Dominant white or near-white background.
* Very dark text.
* Muted electric blue for governed context and production architecture.
* Amber for threshold, caution, and boundary markers.
* Muted green for verified retrieval or controlled output.
* Gray structured panels for context surfaces.
* Clean, calm, serious technical design.
* Avoid decorative noise.
TITLE AND SUBTITLE
Visible title:
Personal Wiki vs Production Context Plane
Visible subtitle:
The boundary changes when the agent serves other people.
REQUIRED LAYOUT
Create a left-to-right split architecture diagram with three major zones:
1. Personal second brain
2. Production threshold
3. Governed context plane
Zone 1 should show one user, one local agent, and one markdown or notes folder. It should feel simple, portable, owner-controlled, and inspectable.
Zone 2 should show a visible threshold labeled through symbols and structure, not tiny text. It should represent the moment the agent is shipped to other users.
Zone 3 should show many users entering a production agent boundary. The production agent must connect to a governed context plane with separate rails for business context, user memory, generated tools, permissions, and evidence.
REQUIRED LABELS
Include these labels exactly:
* One user
* Local notes
* Markdown wiki
* Ship to others
* Many users
* Production agent
* Context plane
* Business context
* User memory
* Access gate
* Evidence trail
MANDATORY CALLOUTS
Include three callouts:
1. "Personal agents can live in files."
2. "Production agents need boundaries."
3. "Context becomes architecture."
OUTPUT INTENT
The viewer should understand that markdown is not bad. The problem is promoting a personal memory pattern into a multi-user production boundary.
DO NOT
Do not include Redis branding.
Do not include vendor logos.
Do not imply Redis is required.
Do not show robots, glowing brains, humanoid AI faces, fake dashboards, or cyberpunk clutter.
Do not include raw transcript text.
Do not include source packet files.
Do not use tiny unreadable text.
Do not make markdown look obsolete.
Do not turn the context plane into a generic cloud diagram.Dark Expressive Prompt
PRIMARY GOAL
Create a premium 16:9 dark expressive teaching graphic that explains the central thesis: the personal second brain and the production context plane are different architectural categories. The graphic must feel like a serious technical field manual, not a SaaS landing page.
AUDIENCE
AI architects, enterprise platform leaders, engineering managers, agent builders, governance teams, and senior technologists evaluating when a local knowledge base stops being enough.
FORMAT AND ASPECT RATIO
Single static editorial infographic, 16:9 landscape. Suitable for a dark SharePlane hero visual or section opener. No animation.
VISUAL SYSTEM
Use a dark expressive visual system:
* Near-black or graphite background.
* High-contrast cream or near-white text.
* Muted electric blue for context-plane structure.
* Amber for threshold gates and boundary warnings.
* Muted green for verified or controlled retrieval.
* Subtle gridlines, trace lines, diagnostic labels, and schematic rails.
* Serious field-manual energy, not neon entertainment.
TITLE AND SUBTITLE
Visible title:
Personal Wiki vs Production Context Plane
Visible subtitle:
The boundary changes when the agent serves other people.
REQUIRED LAYOUT
Create a split-field composition:
Left side:
A compact personal workspace with one user, one local agent, markdown files, and a small owner-controlled boundary.
Center:
A tall amber threshold gate showing the shift from personal ownership to production responsibility.
Right side:
A larger production context plane with many users, a production agent boundary, generated tools, business context rail, user memory rail, access-control gate, and evidence trail.
The right side should feel more complex but disciplined, not chaotic.
REQUIRED LABELS
Include these labels exactly:
* One user
* Local notes
* Markdown wiki
* Ship to others
* Many users
* Production agent
* Context plane
* Business context
* User memory
* Access gate
* Evidence trail
MANDATORY CALLOUTS
Include three callouts:
1. "Personal agents can live in files."
2. "Production agents need boundaries."
3. "Context becomes architecture."
OUTPUT INTENT
The viewer should understand the trust-boundary shift immediately. This is not a database preference. It is a responsibility boundary.
DO NOT
Do not include Redis branding.
Do not include vendor logos.
Do not use Redis red as the dominant color.
Do not show robots, glowing brains, humanoid AI faces, fake hologram dashboards, or generic cyberpunk overload.
Do not include raw transcript text.
Do not include source packet files.
Do not use tiny unreadable text.
Do not imply markdown is dead.
Do not imply a specific vendor is required.Prompt 02: Business Context and User Memory Are Different JobsMainline White + Dark Expressive
Mainline White Prompt
PRIMARY GOAL
Create a premium 4:3 teaching graphic that separates business context from user memory in a production agent architecture. The visual must make clear that these are different context jobs with different risks, lifecycle rules, and access boundaries.
AUDIENCE
AI architects, agent platform teams, enterprise application owners, product managers, governance teams, and technical leaders designing production agent systems.
FORMAT AND ASPECT RATIO
Single static editorial infographic, 4:3 landscape or near-square. Suitable for a SharePlane section graphic or architecture explainer card. No animation.
VISUAL SYSTEM
Use the Mainline White visual system:
* Dominant white or near-white background.
* Very dark text.
* Muted blue for business context.
* Muted green for user memory.
* Amber for access, lifecycle, and governance boundaries.
* Gray for neutral structure.
* Clean technical editorial layout.
TITLE AND SUBTITLE
Visible title:
Business Context and User Memory Are Different Jobs
Visible subtitle:
Operational truth and user-specific memory must not collapse into one pile.
REQUIRED LAYOUT
Create a two-rail architecture diagram feeding a central production agent.
Left rail:
Business context. Show structured entity cards for customers, orders, shipments, policies, tickets, products, entitlements, and current state. The rail must pass through a tool gateway and access gate.
Right rail:
User memory. Show session state, preferences, prior interactions, durable facts, learned patterns, and recall hooks. The rail must show lifecycle and scope markers.
Center:
Production agent. The agent receives governed business context and scoped user memory through defined interfaces.
Bottom:
Evidence trail and inspection layer.
REQUIRED LABELS
Include these labels exactly:
* Business context
* Current state
* Generated tools
* Access gate
* User memory
* Session state
* Long-term memory
* Scoped recall
* Production agent
* Evidence trail
MANDATORY CALLOUTS
Include three callouts:
1. "Business context answers what is true now."
2. "User memory answers what this user carries forward."
3. "Do not merge memory into truth."
OUTPUT INTENT
The viewer should understand that production agents need separate surfaces for business data and user-specific memory.
DO NOT
Do not include real customer data.
Do not include medical, financial, employer, or regulated examples.
Do not include SQL, database screenshots, fake dashboards, vendor logos, or Redis branding.
Do not show user memory as a magical brain.
Do not use tiny unreadable text.
Do not imply one rail is optional when the agent serves users across sessions.Dark Expressive Prompt
PRIMARY GOAL
Create a premium 4:3 dark expressive architecture card that shows business context and user memory as separate production-agent surfaces. The graphic must feel like a systems boundary diagram, not a memory-product ad.
AUDIENCE
AI architects, production agent builders, governance teams, platform engineers, data owners, and technical product leaders.
FORMAT AND ASPECT RATIO
Single static editorial infographic, 4:3. Suitable for a dark SharePlane architecture card. No animation.
VISUAL SYSTEM
Use a dark expressive visual system:
* Near-black or graphite background.
* High-contrast near-white text.
* Muted blue for business context.
* Muted green for user memory.
* Amber for gates, TTL, scope, and lifecycle markers.
* Schematic rails, diagnostic labels, and serious field-guide structure.
TITLE AND SUBTITLE
Visible title:
Business Context and User Memory Are Different Jobs
Visible subtitle:
Operational truth and user-specific memory need separate boundaries.
REQUIRED LAYOUT
Create a central production agent node fed by two disciplined rails.
Left rail:
Business context with structured entity blocks, live-state markers, generated tool cards, and access tags.
Right rail:
User memory with session memory, long-term memory, preference cards, learned-pattern markers, and lifecycle controls.
Below both rails:
Evidence trail, retrieval log, and review surface.
REQUIRED LABELS
Include these labels exactly:
* Business context
* Current state
* Generated tools
* Access gate
* User memory
* Session state
* Long-term memory
* Scoped recall
* Production agent
* Evidence trail
MANDATORY CALLOUTS
Include three callouts:
1. "Business context is not user memory."
2. "Memory needs scope."
3. "Retrieval needs evidence."
OUTPUT INTENT
The viewer should understand that a production agent needs governed access to current operational data and separately scoped memory about the user.
DO NOT
Do not include vendor branding.
Do not include Redis UI or Redis logos.
Do not include fake readable private records.
Do not include medical, employer, or regulated examples.
Do not show glowing brains or robots.
Do not use raw transcript text.
Do not make the diagram look like generic cloud architecture.Prompt 03: The Blast Radius TestMainline White + Dark Expressive
Mainline White Prompt
PRIMARY GOAL
Create a premium 16:9 decision graphic that helps leaders decide whether a markdown wiki is enough or whether a production context plane is required. The core idea is blast radius: who is affected when the agent retrieves, remembers, or answers incorrectly?
AUDIENCE
Engineering leaders, AI platform owners, enterprise architects, risk owners, product managers, and technical operators evaluating agent readiness.
FORMAT AND ASPECT RATIO
Single static editorial infographic, 16:9 landscape. Suitable for a decision-rule section or executive briefing slide. No animation.
VISUAL SYSTEM
Use the Mainline White visual system:
* White or near-white background.
* Very dark text.
* Amber for thresholds and caution markers.
* Muted blue for production context.
* Restrained red-orange for risk expansion.
* Muted green for governed outcomes.
* Clean diagrammatic style with minimal decoration.
TITLE AND SUBTITLE
Visible title:
The Blast Radius Test
Visible subtitle:
Who owns the consequences when the agent gets context wrong?
REQUIRED LAYOUT
Create a progression from small personal blast radius to production blast radius.
Left:
A small circle around one user, one agent, and one markdown folder.
Center:
A threshold checklist with boundary markers:
many users, live data, access control, memory across sessions, explainability.
Right:
A larger production radius with user clusters, live data rails, permission gates, scoped memory, retrieval logs, and audit trail.
Use a decision path through the thresholds.
REQUIRED LABELS
Include these labels exactly:
* One owner
* Small blast radius
* Many users
* Live data
* Access control
* Session memory
* Explainability
* Production blast radius
* Context plane required
MANDATORY CALLOUTS
Include three callouts:
1. "If the blast radius is only you, keep it simple."
2. "If the blast radius includes users, govern the context."
3. "A good demo is not a safe boundary."
OUTPUT INTENT
The viewer should understand that architecture changes when context errors affect other people, business data, or trust boundaries.
DO NOT
Do not show literal explosions, disasters, skulls, fire, fearmongering, or hacker imagery.
Do not include vendor logos.
Do not include fake dashboards.
Do not include private data.
Do not use tiny unreadable text.
Do not turn the visual into compliance theater.
Do not imply every personal project needs enterprise architecture.Dark Expressive Prompt
PRIMARY GOAL
Create a premium 16:9 dark expressive diagnostic visual that shows why a personal memory pattern becomes unsafe when the agent crosses into production. The visual must make the blast-radius threshold impossible to miss.
AUDIENCE
AI architects, engineering leaders, agent platform teams, governance teams, and technical executives.
FORMAT AND ASPECT RATIO
Single static editorial infographic, 16:9 landscape. Suitable for a dark diagnostic section opener. No animation.
VISUAL SYSTEM
Use a dark expressive visual system:
* Near-black or graphite background.
* High-contrast near-white text.
* Amber for threshold gates.
* Muted blue for production context surfaces.
* Restrained red-orange for risk expansion.
* Muted green for controlled paths.
* Field-manual labels, radius rings, and diagnostic trace marks.
TITLE AND SUBTITLE
Visible title:
The Blast Radius Test
Visible subtitle:
Who owns the consequences when the agent gets context wrong?
REQUIRED LAYOUT
Create two visual fields:
Left field:
A tight single-user radius around a local agent and markdown folder.
Right field:
Wider concentric rings showing many users, live data, permissions, user memory, retrieval, and audit.
Between them:
A threshold gate with clear boundary markers.
The transition should feel sober, not dramatic.
REQUIRED LABELS
Include these labels exactly:
* One owner
* Small blast radius
* Many users
* Live data
* Access control
* Session memory
* Explainability
* Production blast radius
* Context plane required
MANDATORY CALLOUTS
Include three callouts:
1. "If the blast radius is only you, keep it simple."
2. "If the blast radius includes users, govern the context."
3. "A good demo is not a safe boundary."
OUTPUT INTENT
The viewer should understand that the architectural threshold is responsibility, not taste.
DO NOT
Do not show explosions, horror imagery, skulls, flames, hacker masks, or disaster scenes.
Do not include Redis branding.
Do not include vendor logos.
Do not include fake dashboards.
Do not use raw transcript text.
Do not make the graphic anti-markdown.
Do not use tiny unreadable text.Prompt 04: Context Plane, Not Junk DrawerMainline White + Dark Expressive
Mainline White Prompt
PRIMARY GOAL
Create a premium 21:9 editorial architecture banner that contrasts ungoverned retrieval with a governed context plane. The visual must show why dumping files, memories, and data fragments into one retrieval pile is not production architecture.
AUDIENCE
AI architects, platform owners, knowledge-system designers, data owners, engineering leaders, and teams moving from prototype agents into production systems.
FORMAT AND ASPECT RATIO
Single static editorial infographic, 21:9 cinematic landscape. Suitable for a wide SharePlane section banner. No animation.
VISUAL SYSTEM
Use the Mainline White visual system:
* Warm white or near-white background.
* Dark text.
* Gray structured panels.
* Muted blue for governed context surfaces.
* Amber for cautions and gates.
* Restrained red-orange for ungoverned risk.
* Muted green for verified paths.
TITLE AND SUBTITLE
Visible title:
Context Plane, Not Junk Drawer
Visible subtitle:
Retrieval is useful only when the boundaries are visible.
REQUIRED LAYOUT
Create a wide contrast composition.
Left third:
An ungoverned junk drawer of loose notes, stale snippets, memory fragments, database pieces, and broken arrows flowing toward an agent.
Right two-thirds:
A governed context plane with distinct rails:
source classes, generated tools, access tags, memory scope, retrieval logs, and verification markers.
Make the right side visibly cleaner, stronger, and safer without making it look bureaucratic.
REQUIRED LABELS
Include these labels exactly:
* Ungoverned retrieval
* Loose notes
* Stale fragments
* Context plane
* Source classes
* Generated tools
* Access tags
* Memory scope
* Retrieval log
* Verification marker
MANDATORY CALLOUTS
Include three callouts:
1. "More context is not the same as better context."
2. "A pile is not a plane."
3. "Govern the boundary before scaling the agent."
OUTPUT INTENT
The viewer should understand that context quality comes from structure, scope, permission, and evidence, not from shoving more material into retrieval.
DO NOT
Do not include vendor logos.
Do not include Redis branding.
Do not show real user data or company examples.
Do not include raw transcript text.
Do not include source packet files.
Do not make the junk drawer look cute or harmless.
Do not use tiny unreadable text.
Do not use generic cloud icons as the main metaphor.Dark Expressive Prompt
PRIMARY GOAL
Create a premium 21:9 dark expressive architecture banner that shows the difference between ungoverned retrieval chaos and a governed production context plane. The visual must feel like a serious systems warning without becoming melodrama.
AUDIENCE
AI architects, production agent builders, engineering leaders, data owners, governance teams, and technical executives.
FORMAT AND ASPECT RATIO
Single static editorial infographic, 21:9 cinematic landscape. Suitable for a dark SharePlane banner. No animation.
VISUAL SYSTEM
Use a dark expressive visual system:
* Near-black or graphite background.
* High-contrast near-white text.
* Muted blue for the governed context plane.
* Amber for boundaries and caution gates.
* Restrained red-orange for ungoverned risk.
* Muted green for verified retrieval.
* Schematic rails, field labels, and trace lines.
TITLE AND SUBTITLE
Visible title:
Context Plane, Not Junk Drawer
Visible subtitle:
Retrieval is useful only when the boundaries are visible.
REQUIRED LAYOUT
Create a left-to-right contrast.
Left:
Chaotic floating fragments, broken arrows, loose notes, and memory scraps being pulled into an agent without boundaries.
Right:
A disciplined context plane with parallel rails for business context, user memory, access policy, retrieval log, source posture, and evidence trail.
The right side should dominate visually.
REQUIRED LABELS
Include these labels exactly:
* Ungoverned retrieval
* Loose notes
* Stale fragments
* Context plane
* Source classes
* Generated tools
* Access tags
* Memory scope
* Retrieval log
* Verification marker
MANDATORY CALLOUTS
Include three callouts:
1. "More context is not the same as better context."
2. "A pile is not a plane."
3. "Govern the boundary before scaling the agent."
OUTPUT INTENT
The viewer should understand that retrieval without governance just moves confusion faster.
DO NOT
Do not include hacker visuals.
Do not include vendor logos.
Do not include Redis branding.
Do not include raw transcript material.
Do not include fake dashboards.
Do not show private data.
Do not use glowing brains, robots, or generic AI magic.
Do not use tiny unreadable text.Prompt 05: Markdown Is Not BrokenMainline White + Dark Expressive
Mainline White Prompt
PRIMARY GOAL
Create a premium 4:3 teaching graphic that defends the personal markdown second-brain pattern while defining its limit. The visual must make markdown look powerful inside the right boundary, not obsolete.
AUDIENCE
AI practitioners, personal knowledge-system builders, coding-agent users, architects, engineering leaders, and technical operators who appreciate simple systems.
FORMAT AND ASPECT RATIO
Single static editorial infographic, 4:3 landscape or near-square. Suitable for a SharePlane section graphic. No animation.
VISUAL SYSTEM
Use the Mainline White visual system:
* White or near-white background.
* Very dark text.
* Soft blue for local agent assistance.
* Warm amber for owner boundary.
* Muted green for portability and versioning.
* Gray for file structure and notes.
* Calm, elegant, respectful technical style.
TITLE AND SUBTITLE
Visible title:
Markdown Is Not Broken
Visible subtitle:
It is brilliant when the owner and the blast radius are the same person.
REQUIRED LAYOUT
Create a clean local workspace diagram.
Show:
One user, one local agent, a markdown folder, a note graph, git history, simple file tree, and an owner-controlled boundary.
The boundary should make the pattern feel intentionally small and strong.
Add subtle markers for:
readable, portable, editable, versioned, local.
REQUIRED LABELS
Include these labels exactly:
* One owner
* Local agent
* Markdown notes
* File tree
* Git history
* Portable
* Editable
* Owner boundary
* Small blast radius
MANDATORY CALLOUTS
Include three callouts:
1. "Simple is a feature."
2. "Local context works when the owner owns the mess."
3. "The pattern fails when it pretends to be production."
OUTPUT INTENT
The viewer should understand that markdown is a strong personal-agent substrate. The artifact is not dunking on the second-brain pattern. It is defining its boundary.
DO NOT
Do not make markdown look dead, obsolete, childish, or inferior.
Do not include vendor logos.
Do not show fake app screenshots.
Do not use people posing at laptops.
Do not include raw transcript text.
Do not use robots or glowing brains.
Do not make the visual anti-personal-knowledge-management.
Do not use tiny unreadable text.Dark Expressive Prompt
PRIMARY GOAL
Create a premium 4:3 dark expressive teaching graphic that shows the markdown second brain as a powerful personal context pattern inside a small owner-controlled boundary.
AUDIENCE
AI practitioners, agent users, technical operators, personal knowledge-system builders, and architects evaluating the limit of local context patterns.
FORMAT AND ASPECT RATIO
Single static editorial infographic, 4:3. Suitable for a dark SharePlane section card. No animation.
VISUAL SYSTEM
Use a dark expressive visual system:
* Near-black or graphite background.
* High-contrast near-white text.
* Muted blue for local agent assistance.
* Warm amber for the owner boundary.
* Muted green for versioned trust.
* Subtle file-tree lines, terminal traces, and note graph cues.
* Serious, clean, technical, not nostalgic.
TITLE AND SUBTITLE
Visible title:
Markdown Is Not Broken
Visible subtitle:
It is brilliant when the owner and the blast radius are the same person.
REQUIRED LAYOUT
Show a single user workspace as a bounded system.
Inside the boundary:
Local agent, markdown folder, note graph, git trail, terminal tile, and simple file structure.
Outside the boundary:
Muted hints of production concerns, kept outside the personal system.
REQUIRED LABELS
Include these labels exactly:
* One owner
* Local agent
* Markdown notes
* File tree
* Git history
* Portable
* Editable
* Owner boundary
* Small blast radius
MANDATORY CALLOUTS
Include three callouts:
1. "Simple is a feature."
2. "Local context works when the owner owns the mess."
3. "The pattern fails when it pretends to be production."
OUTPUT INTENT
The viewer should respect markdown as a powerful personal context tool while understanding why it does not automatically become a production architecture.
DO NOT
Do not mock markdown.
Do not include Redis branding.
Do not include vendor logos.
Do not show fake UI.
Do not show cyberpunk clutter.
Do not include robots, glowing brains, or humanoid AI faces.
Do not include raw transcript material.
Do not use tiny unreadable text.Prompt 06: Production Agent GateMainline White + Dark Expressive
Mainline White Prompt
PRIMARY GOAL
Create a premium 16:9 threshold graphic that shows the exact moment a personal agent becomes a production architecture problem: when it serves other people. The visual must make the gate between local simplicity and production responsibility clear.
AUDIENCE
AI architects, product owners, platform teams, engineering leaders, governance teams, and decision-makers evaluating whether an agent demo is ready for shared use.
FORMAT AND ASPECT RATIO
Single static editorial infographic, 16:9 landscape. Suitable for a SharePlane decision-rule section. No animation.
VISUAL SYSTEM
Use the Mainline White visual system:
* White or near-white background.
* Very dark text.
* Amber for the production gate.
* Muted blue for context-plane structure.
* Gray for local and shared system surfaces.
* Muted green for verified paths.
* Clean, precise, architectural styling.
TITLE AND SUBTITLE
Visible title:
Production Agent Gate
Visible subtitle:
Serving other people changes the system boundary.
REQUIRED LAYOUT
Create a path diagram.
Left:
Local agent with markdown wiki and one owner.
Center:
A strong production gate with threshold markers:
many users, live data, access control, scoped memory, explainability.
Right:
A governed context plane with generated tools, business data, user memory, permission gates, retrieval logs, and evidence trail.
The gate must be visually decisive.
REQUIRED LABELS
Include these labels exactly:
* Local agent
* Markdown wiki
* One owner
* Production gate
* Many users
* Live data
* Access control
* Scoped memory
* Generated tools
* Evidence trail
MANDATORY CALLOUTS
Include three callouts:
1. "The gate is serving other people."
2. "After the gate, context needs governance."
3. "Do not ship the folder as the boundary."
OUTPUT INTENT
The viewer should understand that production readiness is not a prettier demo. It is a boundary change.
DO NOT
Do not include vendor logos.
Do not include Redis branding.
Do not show fake dashboards.
Do not include raw transcript text.
Do not include implementation commands.
Do not make the gate look like security theater.
Do not use tiny unreadable text.
Do not imply every local agent needs production infrastructure.Dark Expressive Prompt
PRIMARY GOAL
Create a premium 16:9 dark expressive threshold diagram titled "Production Agent Gate." The graphic must show that serving other people changes the architecture boundary.
AUDIENCE
AI architects, engineering leaders, agent builders, platform teams, governance owners, and technical executives.
FORMAT AND ASPECT RATIO
Single static editorial infographic, 16:9 landscape. Suitable for a dark SharePlane architecture section. No animation.
VISUAL SYSTEM
Use a dark expressive visual system:
* Near-black or graphite background.
* High-contrast cream or near-white text.
* Amber for the threshold gate.
* Muted blue for context-plane rails.
* Muted green for verified output.
* Schematic lines, diagnostic labels, and technical field-manual energy.
TITLE AND SUBTITLE
Visible title:
Production Agent Gate
Visible subtitle:
Serving other people changes the system boundary.
REQUIRED LAYOUT
Create three zones:
Left:
Personal local agent path with markdown folder and one owner.
Center:
Tall amber gate with visible threshold markers.
Right:
Production context plane with many-user ingress, generated tools, business context, user memory, access gate, and evidence trail.
The visual should feel disciplined, not theatrical.
REQUIRED LABELS
Include these labels exactly:
* Local agent
* Markdown wiki
* One owner
* Production gate
* Many users
* Live data
* Access control
* Scoped memory
* Generated tools
* Evidence trail
MANDATORY CALLOUTS
Include three callouts:
1. "The gate is serving other people."
2. "After the gate, context needs governance."
3. "Do not ship the folder as the boundary."
OUTPUT INTENT
The viewer should understand that the decisive moment is not model choice. It is crossing from personal ownership into shared responsibility.
DO NOT
Do not include Redis branding.
Do not include vendor logos.
Do not use database logos.
Do not include fake UI.
Do not use raw transcript material.
Do not show robots, glowing brains, or generic AI magic.
Do not use tiny unreadable text.Prompt 07: Claim and Caveat LedgerMainline White + Dark Expressive
Mainline White Prompt
PRIMARY GOAL
Create a premium 16:9 evidence-ledger panel that shows why source posture must be visible in a public AI architecture artifact. The graphic must separate source claims, verified support, teaching interpretation, vendor caveats, excluded claims, and implementation caveats.
AUDIENCE
AI architects, governance teams, technical writers, engineering leaders, source reviewers, and SharePlane readers who need to see what is verified, interpreted, caveated, and excluded.
FORMAT AND ASPECT RATIO
Single static editorial infographic, 16:9 landscape. Suitable for a SharePlane claim-ledger section. No animation.
VISUAL SYSTEM
Use the Mainline White visual system:
* White or near-white background.
* Dark text.
* Muted blue for source claims.
* Muted green for verified support.
* Amber for caveats.
* Restrained red-orange for excluded claims.
* Gray for neutral teaching interpretation.
* Precise ledger-table styling.
TITLE AND SUBTITLE
Visible title:
Claim and Caveat Ledger
Visible subtitle:
Evidence posture is part of the architecture.
REQUIRED LAYOUT
Create a structured ledger with six row types:
1. Source claim
2. Verified support
3. Teaching interpretation
4. Vendor caveat
5. Excluded claim
6. Implementation caveat
Each row should include a status chip, evidence lane, and caveat lane.
REQUIRED LABELS
Include these labels exactly:
* Source claim
* Verified support
* Teaching interpretation
* Vendor caveat
* Excluded claim
* Implementation caveat
* Evidence lane
* Caveat lane
MANDATORY CALLOUTS
Include three callouts:
1. "Demos are not architecture."
2. "Vendor posture is not neutral proof."
3. "Excluded claims protect the artifact."
OUTPUT INTENT
The viewer should understand that this artifact does not flatten source claims into facts. It shows what is supported, what is interpreted, and what is excluded.
DO NOT
Do not invent citations.
Do not include raw transcript text.
Do not show source packet file names as visual material.
Do not include vendor dashboards.
Do not include Redis branding.
Do not imply unresolved claims are verified.
Do not use tiny unreadable text.
Do not make the ledger look like legal clutter.Dark Expressive Prompt
PRIMARY GOAL
Create a premium 16:9 dark expressive provenance panel titled "Claim and Caveat Ledger." The graphic must make evidence posture visible and serious without turning it into legal sludge.
AUDIENCE
AI architects, source reviewers, governance teams, technical leaders, and SharePlane readers evaluating artifact trustworthiness.
FORMAT AND ASPECT RATIO
Single static editorial infographic, 16:9 landscape. Suitable for a dark SharePlane provenance section. No animation.
VISUAL SYSTEM
Use a dark expressive visual system:
* Near-black or graphite background.
* High-contrast near-white text.
* Muted blue for source claims.
* Muted green for verified support.
* Amber for caveats.
* Restrained red-orange for excluded claims.
* Gray for interpretation.
* Clean ledger rows, status chips, and evidence lanes.
TITLE AND SUBTITLE
Visible title:
Claim and Caveat Ledger
Visible subtitle:
Evidence posture is part of the architecture.
REQUIRED LAYOUT
Create a dark structured ledger with six row types:
source claim, verified support, teaching interpretation, vendor caveat, excluded claim, implementation caveat.
Each row should include:
status chip, evidence lane, caveat lane, and a small visual marker.
REQUIRED LABELS
Include these labels exactly:
* Source claim
* Verified support
* Teaching interpretation
* Vendor caveat
* Excluded claim
* Implementation caveat
* Evidence lane
* Caveat lane
MANDATORY CALLOUTS
Include three callouts:
1. "Demos are not architecture."
2. "Vendor posture is not neutral proof."
3. "Excluded claims protect the artifact."
OUTPUT INTENT
The viewer should understand that trust comes from keeping claim posture visible.
DO NOT
Do not invent citations.
Do not include Redis branding.
Do not include vendor logos.
Do not show fake dashboards.
Do not include raw transcript text.
Do not show source packet files.
Do not imply unresolved claims are facts.
Do not use tiny unreadable text.Prompt 08: The Architecture RuleMainline White + Dark Expressive
Mainline White Prompt
PRIMARY GOAL
Create a premium 21:9 closing synthesis banner that visualizes the final rule: personal agents can live in files, but production agents need a context plane. The visual must feel like the clean conclusion of the artifact.
AUDIENCE
AI architects, platform leaders, engineering leaders, governance teams, and builders moving from personal AI workflows to production agent systems.
FORMAT AND ASPECT RATIO
Single static editorial infographic, 21:9 cinematic landscape. Suitable for a SharePlane closing banner and social crop candidate. No animation.
VISUAL SYSTEM
Use the Mainline White visual system:
* Warm white or near-white background.
* Very dark text.
* Muted blue for production context.
* Amber for the boundary threshold.
* Muted green for controlled retrieval and evidence.
* Gray for local file structure and neutral infrastructure.
* Elegant, clear, executive-grade architecture style.
TITLE AND SUBTITLE
Visible title:
Personal Agents Can Live in Files. Production Agents Need a Context Plane.
Visible subtitle:
The difference is not sophistication. The difference is responsibility.
REQUIRED LAYOUT
Create a wide synthesis diagram.
Left side:
A clean file-based personal agent system with one user, local agent, markdown folder, git history, and small owner boundary.
Center:
A threshold arrow or gate showing the move from personal ownership to production responsibility.
Right side:
A governed context plane with many users, production agent, business context, user memory, generated tools, access control, retrieval log, and evidence trail.
REQUIRED LABELS
Include these labels exactly:
* Personal agent
* Files
* One owner
* Production agent
* Context plane
* Business context
* User memory
* Generated tools
* Access control
* Evidence trail
MANDATORY CALLOUTS
Include three callouts:
1. "Keep personal systems simple."
2. "Govern shared systems deliberately."
3. "The context boundary is the product boundary."
OUTPUT INTENT
The viewer should walk away with the artifact’s decision rule in one glance.
DO NOT
Do not include vendor branding.
Do not include Redis logos or Redis color dominance.
Do not include fake dashboards.
Do not include raw transcript text.
Do not include source packet files.
Do not show people, robots, glowing brains, or generic AI icons.
Do not make the architecture look like a vendor reference diagram.
Do not use tiny unreadable text.Dark Expressive Prompt
PRIMARY GOAL
Create a premium 21:9 dark expressive closing synthesis banner that lands the artifact’s final rule: personal agents can live in files, production agents need a context plane.
AUDIENCE
AI architects, platform teams, engineering executives, governance leaders, and technical operators designing agent systems.
FORMAT AND ASPECT RATIO
Single static editorial infographic, 21:9 cinematic landscape. Suitable for a dark closing banner and social preview. No animation.
VISUAL SYSTEM
Use a dark expressive visual system:
* Near-black or graphite background.
* High-contrast cream or near-white text.
* Muted electric blue for context-plane rails.
* Amber for the threshold.
* Muted green for verified retrieval.
* Gray for file systems and neutral infrastructure.
* Serious technical field-guide energy.
TITLE AND SUBTITLE
Visible title:
Personal Agents Can Live in Files. Production Agents Need a Context Plane.
Visible subtitle:
The difference is not sophistication. The difference is responsibility.
REQUIRED LAYOUT
Create a left-to-right synthesis:
Left:
Compact personal file-based system with one user, local agent, markdown folder, and owner boundary.
Center:
Sharp amber threshold line representing the move into shared responsibility.
Right:
Disciplined production context plane with many-user ingress, production agent, business-context rail, user-memory rail, generated tools, access gate, retrieval log, and evidence trail.
REQUIRED LABELS
Include these labels exactly:
* Personal agent
* Files
* One owner
* Production agent
* Context plane
* Business context
* User memory
* Generated tools
* Access control
* Evidence trail
MANDATORY CALLOUTS
Include three callouts:
1. "Keep personal systems simple."
2. "Govern shared systems deliberately."
3. "The context boundary is the product boundary."
OUTPUT INTENT
The viewer should remember the rule without reading the full article.
DO NOT
Do not include Redis branding.
Do not include vendor logos.
Do not use glowing red vendor aesthetics.
Do not include fake UI.
Do not include raw transcript text.
Do not show source packet material.
Do not show people, robots, or glowing brains.
Do not use tiny unreadable text.Prompt 09: Capstone Cover VisualMainline White + Dark Expressive
Mainline White Prompt
PRIMARY GOAL
Create a premium 16:9 editorial cover image for the SharePlane artifact "Your Second Brain Is Not a Production Architecture." The visual must capture the full thesis: markdown is excellent for personal agents, but production agents require governed context.
AUDIENCE
SharePlane readers, AI architects, platform leaders, engineering leaders, governance teams, and technical product builders.
FORMAT AND ASPECT RATIO
Single static editorial cover image, 16:9 landscape. Suitable for artifact hero, card image, and social preview. No animation.
VISUAL SYSTEM
Use the Mainline White visual system:
* Dominant white or near-white background.
* Dark primary text.
* Muted electric blue for production context.
* Amber for the threshold.
* Gray for local notes and file systems.
* Muted green for verified paths.
* Premium editorial architecture style.
TITLE AND SUBTITLE
Visible title:
Your Second Brain Is Not a Production Architecture
Visible subtitle:
Personal context is not the same as a production boundary.
REQUIRED LAYOUT
Create a polished split-cover composition.
Left third:
Personal second-brain workspace with markdown folders, git traces, note graph, and one local agent.
Center:
A sharp threshold marker.
Right two-thirds:
Production context plane with many-user ingress, generated tools, business context, user memory, access gates, retrieval log, and evidence trail.
Leave title-safe space in the upper left or upper center.
REQUIRED LABELS
Include these labels exactly:
* Second brain
* Markdown
* Local agent
* Production agent
* Context plane
* Business context
* User memory
* Access gate
* Evidence trail
MANDATORY CALLOUTS
Include three callouts:
1. "Markdown is not broken."
2. "The boundary changes when you ship."
3. "Production needs a context plane."
OUTPUT INTENT
The viewer should understand the artifact’s entire argument from the cover image.
DO NOT
Do not include Redis branding.
Do not include vendor logos.
Do not include fake dashboards.
Do not show people posing.
Do not show robots, glowing brains, or humanoid AI.
Do not include raw transcript snippets.
Do not include private data.
Do not imply Redis is required.
Do not use tiny unreadable text.Dark Expressive Prompt
PRIMARY GOAL
Create a premium 16:9 dark expressive editorial cover for the SharePlane artifact "Your Second Brain Is Not a Production Architecture." The visual must feel like a serious technical artifact, not AI hype art.
AUDIENCE
SharePlane readers, AI architects, production-agent builders, platform owners, engineering leaders, and governance teams.
FORMAT AND ASPECT RATIO
Single static editorial cover image, 16:9 landscape. Suitable for dark hero, artifact card, and social preview. No animation.
VISUAL SYSTEM
Use a dark expressive visual system:
* Near-black or graphite background.
* High-contrast cream or near-white text.
* Muted electric blue for context-plane structure.
* Amber for the production threshold.
* Muted green for verified retrieval.
* Gray for local file and note structures.
* Schematic rails, trace lines, and diagnostic precision.
TITLE AND SUBTITLE
Visible title:
Your Second Brain Is Not a Production Architecture
Visible subtitle:
Personal context is not the same as a production boundary.
REQUIRED LAYOUT
Create a dramatic but controlled split-cover layout.
Left third:
Quiet local markdown/wiki workspace with one user boundary, markdown folder, local agent, and note graph.
Center:
Sharp amber threshold line.
Right two-thirds:
Governed production context plane with many users, production agent, generated tools, business context, user memory, access gates, retrieval log, and evidence trail.
Leave clean title-safe space.
REQUIRED LABELS
Include these labels exactly:
* Second brain
* Markdown
* Local agent
* Production agent
* Context plane
* Business context
* User memory
* Access gate
* Evidence trail
MANDATORY CALLOUTS
Include three callouts:
1. "Markdown is not broken."
2. "The boundary changes when you ship."
3. "Production needs a context plane."
OUTPUT INTENT
The viewer should see the boundary shift instantly: personal context is a working surface; production context is a governed system plane.
DO NOT
Do not include Redis branding.
Do not include vendor logos.
Do not use Redis red as the dominant design language.
Do not include fake dashboards.
Do not include literal code.
Do not show humans, robots, glowing brains, or cyberpunk clutter.
Do not include raw transcript material.
Do not imply a product endorsement.
Do not use tiny unreadable text.Public-safe boundary
This material is personal educational work based on public source material, public documentation, and independent analysis. It does not represent an employer, client, vendor, or platform endorsement. It does not disclose confidential information, controlled documents, internal systems, regulated records, security details, implementation-specific designs, or company-approved policy.
Check the work, not just the conclusion.
Public research, authority, lineage, and author testimony are labeled separately. Sources can corroborate, challenge, or bound the argument; they do not replace Tony Malott's judgment.
Take the complete artifact with you.
The deterministic package contains a self-contained offline article, the exact public-route snapshot, canonical public metadata, receipt, source text when available, plain-text context, claim ledger, source records, and a member-hash manifest.
Sources, authority, and lineage
Each record states the role it plays. Research support and governance provenance are not treated as interchangeable.
I Love the Karpathy LLM Wiki but It Doesn't Scale. Here's What Does.
narrative source and teaching prompt
Public YouTube source packet for R-5_2nsF_ZM: Cole Medin, “I Love the Karpathy LLM Wiki but it Doesn't Scale. Here's What Does.”
Open sourceRedis Iris context-engine documentation
current terminology and capability verification
Current Redis documentation is used to verify Redis Iris terminology and capability framing.
Open sourcecoleam00/redis-iris-agent
implementation posture and preview caveat verification
The Redis demo repo is used to verify the implementation posture and preview caveat.
Open sourceMerged predecessor source record for Your Second Brain Is Not a Production Architecture
Anchors the owner-approved, merged, creatively locked public-safe source and its claim/provenance record.
Anchors the owner-approved, merged, creatively locked public-safe source and its claim/provenance record.
Open sourceSharePlane Platform corpus design authority
Governs platform-native corpus presentation and migration batches.
Governs platform-native corpus presentation and migration batches.
Open sourceWhat is asserted—and how it is bounded
Research, author analysis, and personal testimony remain distinct. Supporting links and caveats stay attached to each claim.
Markdown is strong for personal agents
Boundary Publish confidently.
Personal agents and production agents are different categories
Boundary Core framing.
Production agents need governed access to business data
Boundary Publish vendor-neutral.
Production agents need scoped user memory
Boundary Publish vendor-neutral.
Redis Iris currently lists four services in docs
Boundary Avoid repeating the source-description five-tool framing without caveat.
Redis Search appears in the video description's five-tool framing
Boundary Mention only as a source caveat, not current Iris taxonomy.
Context Retriever and Agent Memory are preview in the demo repo
Boundary Publish in source dossier.
Redis is the best platform
Boundary Excluded from the thesis.
Millions of memories per user
Boundary Excluded unless separately verified.
Pydantic AI is the best framework
Boundary Excluded from the thesis.
Public boundary. No raw transcript, subtitle files, source packet files, screenshots, employer material, internal documents, local paths, controlled information, backend service, runtime AI, analytics, package tooling, external font, remote asset, or dependency is published.
Continue the thinking
Each connection explains why the next work belongs here. The graph records the edge; this layer makes it useful to a reader.