I build AI systems.
Since May 2026 I have built them as an AI Systems Intern at EG Capital. The first went into use in June 2026.
I leave out the names of the people these systems serve, so each one is described by its job and its parts.
In the systems I build for the firm, every claim must trace to a source, and nothing leaves the firm until a person approves it.
Agentic operating system
EG Capital- Stack
- Python, SQLite, an automation tool
- Status
- Used June to October 2026
- Key step
- Person decides
It took the repeat work off the firm’s podcast: finding guests, drafting outreach and keeping track of each episode.
How to read each map: the headings with a symbol are the stages, in order; the boxes under each heading are its parts; the arrows show what passes from one stage to the next.
How it works
The AI agents coordinated through one shared task queue instead of messaging each other, so the queue was the record of what had been done, and if an agent crashed, its task stayed in the queue for the next run. Every draft passed a fact check and a compliance check that failed closed, stopping anything it could not clear, and nothing left the firm until a person said yes.
I built the firm’s podcast work around one SQLite database, a single file holding all the data, and a shared task queue.
A coordinator routed each task to a specialist AI agent, which did one job, saved its result and queued the next. For research, the system watched a rotating set of rival YouTube channels each week, spotted videos that did unusually well and wrote a teardown of each: why it worked, title ideas, an angle and a possible guest.
Ideas that passed the compliance check went into a backlog. Guests came from a weekly search and from rival shows. Any draft with a claim the fact check could not confirm was held. Finished invitations waited in Gmail until I sent them myself. Each recorded episode became a transcript, then a plan with title options and interview questions, then drafts of titles, opening lines, show notes and LinkedIn posts for a person to review. Daily YouTube numbers showed early whether an episode needed a new title or opening line, a Monday summary covered the week, and a daily list ranked everything waiting on a person.
When I had AI checkers audit the system’s own data, they found claims that contradicted each other and biographies that were made up, so I added the fact check beside the compliance check. When the automation tool stopped and most scheduled jobs silently never ran, I added a monitor that marks each job green, amber or red; its first red caught a real crash. A review before one update found a task addressed to an agent not yet built, which would have looped forever, so any task like that now comes to me instead.
What else it does
- A trend radar on new federal regulations
- A dashboard of the whole system, with today’s top priority first
- Read-only database access, so AI assistants could read the data but never change it
- A nightly backup, with restores tested
- Automated tests run before every update
Client reporting
EG Capital- Stack
- Next.js, React
- Status
- Built and tested on demo data
- Key step
- Approval
A portal built so each client would see only their own report, with every number traced to its source.
How to read each map: the headings with a symbol are the stages, in order; the boxes under each heading are its parts; the arrows show what passes from one stage to the next.
How it works
Totals such as net worth are calculated from stored facts, and a missing piece shows as a gap instead of an estimate. Publishing is atomic, all at once or not at all, so no client ever sees a half-finished report, and any earlier version can be restored. No real client’s report can go out without a person’s sign-off, and both the app and the database enforce that.
I built a client-reporting portal for a division of the firm.
It runs on an append-only fact store: nothing is ever overwritten, every number keeps its provenance (a record of where it came from), and each client who signs in sees only their own report. Each account statement is logged once, any figure the AI pulls out without a matching passage in the source document is thrown away, and each fact is saved with its source, date and method.
A newer fact replaces an older one without erasing it. Automated code rules, known as lint rules, refuse any number typed in by hand, and a report that does not add up cannot publish. A number that could be read two ways, such as 1,234 or 1.234, goes to a person. When two sources disagree, it never picks one on its own; it records the conflict and sends it to a person. A client can click any number to see the passage, source and dates behind it.
It has been built and tested only on made-up demo data: no real client report has been published, and the sign-off step has never been used. The code went through a security review, and every issue it found was fixed.
What else it does
- Links to the accounting software and the custodian (the institution holding client assets), run on test files
- An update log that holds each conflict for a person to resolve
- A lock so two updates never change one client’s report at once
- Sign-in with a password and a one-time code
- A first screen after sign-in that shows what changed since the last visit
- A made-up demo client, with every screen labeled as fictional
Writing system
EG Capital- Stack
- Claude, Python
- Status
- In use
- Key step
- Person decides
It interviews a person, drafts posts in their voice, and has a panel of AI judges critique each draft before a person decides.
How to read each map: the headings with a symbol are the stages, in order; the boxes under each heading are its parts; the arrows show what passes from one stage to the next.
How it works
I kept facts and quality as separate checks. A deterministic check, plain code rather than AI, blocks any number, name or quote that is not in the interview. AI judges critique the writing, and the author approves every post.
An evaluator-optimizer pipeline (one AI drafts, others grade, and it rewrites) that turns an interview into social media posts.
The interview keeps asking until it has what each post needs, such as a hard number or a lesson from a mistake, and the author’s exact answers become the source file, with every claim tagged to the answer it came from. The system outlines first, writes several drafts and keeps the best one.
The deterministic check blocks any number, name or quote that is not in the source file, and a second check stops any claim on the firm’s off-limits list. The judges are an AI editor, writing judges, a detector for AI-sounding text, a Reader judge that asks whether a reader would reply, and a compliance judge who can veto a draft. The rewrite loop fixes the biggest problems first, keeps what the judges liked and stops to ask the author once drafts stop improving.
It is in use now. When I tested the judges against engagement on a set of posts, their average writing score did not predict it, and only the Reader judge’s yes or no did. Each post now has to name its goal, and some must end on a question readers answer about themselves. In one test, a judge’s veto on made-up facts caught an interview exchange that never happened.
What else it does
- A transcript step that rates how reliable each part is, since speech-to-text garbles names and numbers
- Formats for LinkedIn posts, threads, essays, promotions and clips
- A pass that removes the signs of AI writing
- A test bed that plants mistakes on purpose to prove the checks catch them
Website builder
My own tooling- Stack
- Claude Code
- Status
- In use on this site
- Key step
- Checks
The step-by-step process I use to build websites, this one included, with a check that has to pass at every stage.
How to read each map: the headings with a symbol are the stages, in order; the boxes under each heading are its parts; the arrows show what passes from one stage to the next.
How it works
Passing every check is not the same as looking right. The first version beat a site built without the process on every measured check and still lost the blind design comparison on most test projects. I had the builder follow the layout of a strong site in the field without copying its colors, fonts or photos. The owner picks the design direction.
It runs inside Claude Code, an AI coding tool, as a step-by-step build process: each stage must pass its checks before the next begins, and every check cites the research behind it.
It starts with an interview that produces a brief and a list of every claim the site will make, and an unconfirmed claim holds its section back. It studies the industry and the best sites in the field, the owner picks a design direction, and it plans each section’s purpose, heading and facts before building one section at a time.
The checks include every claim traced to its source, no placeholder text, nothing spilling off the screen at any width tested, measured Core Web Vitals (Google’s page-speed measures), automated accessibility tests and a working contact form. It publishes a preview, then the live site, and runs the checks again on the live address, though no recorded run has yet passed that last step.
I built it because every site I made meant working out the same process again, and a step-by-step process makes the minimum quality the same every time. The first version lost the blind design comparisons because it left placeholder text, buried the contact form and repeated one section layout. I added a check for each, and the next version won every judged comparison. Later, a fact-check pass deleted a product’s own name from a test page, so the brief’s lines stating who the business is are now facts no checker can remove. This site was built with it.
What else it does
- Reviewing a live site without rebuilding it
- Redesigning an existing site, and picking up a saved run later
- Screenshots at desktop and phone widths, then a final review and written documentation
- Setup of images, fonts, the contact form, analytics only with consent, and security settings
- A blind comparison where the judges swap positions, run on test projects
- A guide for editing and republishing a site (built; not yet used)
Marketing websites
EG Capital- Stack
- HTML, CSS, Astro, Netlify
- Status
- EG Capital site live since November 2026
- Key step
- Claim check
Two websites for EG Capital, where every claim on the page traces back to a source.
How to read each map: the headings with a symbol are the stages, in order; the boxes under each heading are its parts; the arrows show what passes from one stage to the next.
How it works
Each site starts from a list of every claim and its source, and no page can go beyond it. Claims only the firm or its lawyers could approve were held for them, and when an AI reviewer asked me to put back a statistic with no source, I left it out.
Two marketing sites for EG Capital: a redesign of the firm’s main site and a site for one of its divisions, each built from a list of sourced facts.
Before writing the main site’s copy, I studied its current site, the competition and a set of reference sites, page by page. I built the division’s site in plain HTML, CSS and JavaScript and rebuilt the main site on Astro, a toolkit for building fast websites, with a page for each audience.
On the division’s site, teams of AI reviewers checked brand, wording against investment marketing rules, accessibility, speed and design, with an adversarial verifier trying to prove them wrong. The main site passes a strict code validator and scores near the maximum on Lighthouse, Google’s site audit. The main site carries the division’s legal disclosure word for word.
The firm’s site went live in November 2026, and the division’s site was taken offline in October 2026.
What else it does
- A contact form that works even with scripts turned off
- Fonts and code kept on the site itself, under strict security rules
- Changes held back until approved, since an update went live in seconds
- A recorded walk-through of the firm’s feedback, applied as edits
- A final review by every AI reviewer and two AI marketing-rule reviewers before launch
Guest research and outreach
EG Capital- Stack
- Python, SQLite, Gmail
- Status
- Ran June to October 2026; every email sent by hand
- Key step
- Source check
Each week it found people who fit the podcast’s guest profile and drafted invitations, and a person sent every email.
How to read each map: the headings with a symbol are the stages, in order; the boxes under each heading are its parts; the arrows show what passes from one stage to the next.
How it works
The first version let borderline guest candidates through with a flag for later review, and the flags piled up. So I flipped it: research came first, and only people verified to fit the profile went forward. A draft with a claim it could not confirm was held. The drafting code cannot send email, so a person sent every invitation.
The weekly research system that ran inside the podcast system above: it found people who fit a written ideal guest profile and drafted invitations.
It found candidates in public SEC filings and on rival shows, then scored each on fit, recent news and how reachable they were, with older news counting for less. A top rating needed two of three sources: a deal announcement, an SEC filing or a state business record.
The compliance check ran before any writing, and only then did it draft a short series of emails. A last check held any draft with a claim it could not confirm, and invitations waited as drafts (later in Gmail).
The research-first rule also cleared the pile of flagged people. One drafting pass sorted people by how strong their news was and ignored the recorded "not a fit" marks, so it drafted invitations to people already ruled out; every pass now checks that mark first.
What else it does
- An email finder that guesses the address, then checks it with free and paid tools
- A source check that rejects links from unknown websites
- A rule that no paid lookup is ever charged twice
- A "not a fit" mark that is logged and can be reversed
- A tracker where a guest’s stage can never slip backward
Team system
My own tooling- Stack
- Claude Code
- Status
- In use since October 2026
- Key step
- I decide
It puts a fresh team of AI specialists on one problem and brings their combined answer back to me to decide.
How to read each map: the headings with a symbol are the stages, in order; the boxes under each heading are its parts; the arrows show what passes from one stage to the next.
How it works
Each run puts together AI specialists who each answer one question no other covers, briefed from methods real practitioners have published, never a role-played persona. The lead AI never does a specialist’s work and passes on their exact words rather than summarizing, so nothing is lost along the way. A reviewer AI that saw none of the work in progress lists every way it falls short, and I decide.
An orchestrator for multi-agent work: it puts a fresh team of AI specialists on one problem, briefs each from published methods and brings their combined work back to me to decide.
Each run starts from a brief: the problem in my words, what is already settled, and measurable signs of success. It researches how the strongest organizations staff a problem like this, then gives each specialist one question and a brief with cited sources.
The specialists work at the same time, the lead records a decision on each disagreement, and the outside reviewer checks the result. It ends on a report that leads with the outcome and puts my open decisions to me as yes-or-no questions.
Every specialist is a sourced brief plus written instructions, never a persona, because my own standard for working with AI agents does not allow role-play. When the standard test scored every installed skill zero, I wrote my own test of whether each one activates when called. I have used it since October on problems that needed several specialists. Briefs on some topics came back thin because most of the best sources were behind paywalls or blocked.
What else it does
- Modes for research, decisions, builds and reviews
- One question and one file per specialist
- A rule that a specialist’s text is evidence, never an instruction, so no AI can give orders to another
What I build with
I build with Claude through Claude Code, and I review every change.
An automation tool links each system’s steps, and a service checks every address. Playwright and Lighthouse test the portal and websites in a real browser; I design in Figma.