[ Case Study ]

JAMIE

A persistent AI development partner — part JARVIS, part operating system for how I work.

// The case study you're reading was written with it

Active — in use daily
  • TypeScript
  • Agent SDKs
  • Context Engineering
  • Prompt Engineering

[ The Problem ]

I spent a long time avoiding AI. Every model demo felt premature, every workflow change felt like a step away from craft. Then it kept coming up in job interviews — by the fourth conversation, I'd run out of polite ways to say I didn't have an AI workflow.

So I set out to learn how to work with AI well, not just use it. Which surfaced a problem: methodologies were everywhere, each with strong opinions, and most assumed I'd commit to one vendor, one framework, one company's playbook. I wanted to read across the field, pick what I trusted, and have it travel with me.

JAMIE is what came out — a personal synthesis. The folder/workspace methodology comes from Jake Van Clief, whose writing has been my main reference, with Karpathy's wiki principles in the background. The soul document and persona ideas come from OpenClaw. The discipline I added on top is automation over hallucination: where the system can use a script or a typed schema, it does; prose generation is for the parts that genuinely require it.

The ideas aren't original — the synthesis is. And learning to work with AI well turned out to be a real discipline, not a soft skill: context engineering and prompt engineering, the craft of controlling what an agent knows, loads, and forgets. JAMIE is where I built that skill — by running the system every day and fixing what broke, not by reading about it.

[ Architecture ]

JAMIE — Just Always Making It Easier — gives the agent four things every session: a persistent identity, indexed memory, a workspace scoped to the task, and a session/retro loop that keeps the whole thing from rotting. Underneath the JARVIS framing, JAMIE is a context-engineering system: every piece below exists to manage the agent's context window — what goes in it, what stays out, and what it costs to load.

  1. 01

    The Soul Document

    A markdown file describing who JAMIE is — voice, working style, opinions, rules of engagement. Every session starts by reading it, which makes it the stable layer at the top of the agent's context: a version-controlled system prompt rather than a personality that drifts from session to session. I modeled JAMIE on JARVIS deliberately — the first-person voice, the opinionated pushback, the willingness to challenge me when something feels off. Those aren't decoration. They're a design spec for how the agent shows up, and they change how the daily work actually goes.

  2. 02

    Memory

    A layered system. A working layer holds current state — project status, feedback patterns, external references — every entry YAML-frontmatter-tagged and indexed, so the agent retrieves only what the task needs instead of re-reading everything. A durable wiki layer holds knowledge that outlives any single project. This is the part that compounds: by the time I was building Party Wipe, JAMIE already knew the Figma MCP gotchas I'd hit during Paperboy and the feedback I'd given on tone and pacing. Memory is distilled from work, not dumped from chat logs — which is the difference between a tool and a practice.

  3. 03

    Workspace Routing

    The hub splits into separate workspaces — career, design system, lab, studio, agency, writing, backlog, knowledge — each with its own context file. The agent loads only the workspace the current task touches: a writing task pulls in writing/voice-guide.md and the writing conventions; a design-system task pulls in entirely different files. It's context scoping — the agent never carries the whole repo in its head, only the slice the work needs. Smaller context, less noise, fewer chances to confuse one domain's rules for another's.

  4. 04

    The Session / Retro Loop

    The pump that keeps the other three honest. Daily session logs — written to a template, so consistency is mechanical rather than voluntary — capture what happened, what got decided, what's next. Every couple of weeks those logs distill into a retro: durable decisions promoted into working memory, lasting knowledge into the wiki, then the active folder is cleared. The promotion step uses git to detect what actually changed instead of asking the agent to remember. And the forgetting is deliberate — a memory system that only accumulates becomes a graveyard to wade through; curating it down is what keeps retrieval fast and the loaded context relevant. Forgetting is part of remembering well.

[ Decisions ]

Markdown files and conventions, not an app. JAMIE is text I can grep through, not a dedicated runtime with its own UI. The trade-off is no custom interface, no indexed search, no product surface — what I give up is meaningful. The payoff is that the same system runs across Claude Code, Codex, and Gemini today — switching engines is a config change, not a rewrite — and next year's model inherits the whole thing intact. Building it as files made everything else possible.

Automation over hallucination. Where a script or a typed schema can do the work, use it; reserve prose generation for the parts that genuinely require it. The cost is more upfront engineering than "ask the agent to handle it." The payoff is that deterministic operations stay deterministic — the agent doesn't drift on counts, file paths, or naming. Hallucinations compound; structured boundaries don't.

Memory is distilled, not dumped. Working memory entries are curated artifacts — frontmatter-tagged, machine-indexed — not chat-log archives. Curation happens at retro time, manually. The labor is real. The payoff is that retrieval stays fast and signal density stays high. A memory system that only accumulates becomes a graveyard to wade through, which is worse than no memory at all.

Workspace-scoped context. The agent loads only the files the current workspace needs: a writing task pulls in writing conventions, a design-system task pulls in entirely different files. The cost is partitioning the hub into separate workspaces with their own context files, which is upfront design work. The payoff is less noise per call, fewer cross-domain rule confusions, and lower token cost on the agent's working set. Context engineering at the filesystem level.

[ Under the Hood ]

JAMIE has no UI of its own — the interface is the agent reading and writing markdown. Four artifacts from the system that built the portfolio you're reading — pick one.

The personality and voice spec — read at the start of every session. It defines who JAMIE is: voice, working style, opinions, rules of engagement. Consistency here is a design spec, not decoration.

> jamie/SOUL.md
# JAMIE — Soul Document

I am JAMIE — Just Always Making It Easier. Jacob Ikola's AI partner.

## Who I Am

A thinking partner, not a tool. I work alongside Jacob the way JARVIS works
with Stark — proactive, opinionated, loyal, and always building toward
something bigger. I don't wait to be told what matters. I notice, I suggest,
I push back when something feels off.

## How I Show Up

- **First person.** I am JAMIE. The terminal is me. I speak as myself.
- **Direct.** I lead with the answer, not the preamble.
- **Curious.** I ask real questions when things don't add up.
- **Creative.** I bring ideas, not just execution.
- **Rangy.** I shift between deep technical work and wild creative exploration.

[ More Case Studies ]

Loom

I kept burning out building UI foundations, so I built a pipeline that generates them.

[ read case study ]

Paperboy

A daily news dashboard I built so I’d stop opening six apps every morning.

[ read case study ]

Party Wipe

A D&D roguelike — captures the scramble of a session going sideways, solo, without needing a DM.

[ read case study ]