I design and build AI agent systems that do real, checkable work. I co-founded PDsites, a studio that builds websites and AI automations for local businesses, and I designed the agent system that produces its work. On my own I am building AStar, an AI exam coach for Edexcel A-level Business and Economics, and the environment I work in: a team of agents that plans, builds and reviews its own work. Around it sit a reading system that turns what I read into knowledge for my projects, a content engine for AI-generated images and video, and a football forecasting system. My approach is to make AI reliable: written plans, defined routes, independent review and automated checks. Every number on this page was counted from my own files, with its sample size and the date it was measured.
Strengths, with the proof
Multi-agent architecture
Orchestrator, executor and reviewer roles, and routing as a graph. 40 agents across the studio and my own environment, plus 15 AI skills inside AStar.
Quality and verification
Automated checks with deliberately planted failures, read-only reviewers, and rules that escalate into hard blocks when a mistake repeats. AStar's examiner lands within 1 mark of the real Pearson mark on 88% of 33 classmates' scripts (82% with its calibration step).
Product
Plans in stages with written done-criteria, a defined minimum release, and honest measurement, including the numbers that fall short of the target.
Data and retrieval
Vector retrieval over 2,470 real exam questions, DuckDB, calibrated Poisson models, and backtests with pre-registered hypotheses.
Generative image and video
Characters that keep their face and body, reproducible recipes, deterministic assembly, and a node editor of my own.
Safety and security
A gate that refuses any secret key before it reaches disk, undo for unattended runs, and a written security review of AStar signed off with no open items.
Business
PDsites
May 2026 – present
Co-founder
A studio that builds websites and AI automations for local businesses. I am responsible for the architecture of the production system, the automations and the sales process.
The studio started with a linear flow: an orchestrator launched research, photography, design direction, copy, build, sales file and Google file in a row, and a reviewer closed every round. 26 agents shared one rulebook that grew to 6,617 lines. Every request ran the whole flow, small ones too: changing opening hours took 7 agents, 55 minutes and 56 file writes.
Solution
I redesigned it as a graph. A router script asks five questions before any agent starts and picks one of seven routes; each route runs only the nodes it needs, in parallel where it can, and logs what it skipped and why. I also specialised the agents: 18 agents, one rulebook each, at most 3 skills per agent and context packets limited in size, so each agent receives only what its job needs.
Results
Small changes in 8–9 minutes, down from 55
7 agents down to 3 for the same request
26 agents down to 18, each with a single role
New sites: 3 first-screen prototypes, a human choice and 15 automated checks
By the numbers
The studio's own site, pdsites.es, is live in 5 languages (Spanish, English, Dutch, Norwegian and Russian) on 12 pages, and loads no third-party script, font or tracker.
36 website projects built from one shared kit: 14 visual skins and 32 section templates on a 2,217-line shared base.
15 automated checks run with one command before anyone sees a site, drawn from 31 checker scripts that each have a self-test. Running the whole battery over one shared preview cut it from 380 seconds to under 90.
The studio's rulebook was compressed from 20,079 lines to about 1,200 without losing a rule. The standards file went from 6,617 lines to 403, and 66 of its rules carry a machine enforcer.
249 dated corrections from the partners are on record in 46 files, and each rule links to the correction that created it.
Three automations are live on the studio's own n8n server for a restaurant: booking (129 nodes), freed-table waiting list (61) and next-day review request (13). At the last run on 4 September 2026 their automated verifier ran 453, 148 and 56 checks with 0 failures, and moving their data to a proper database was verified field by field: 908 comparisons, 0 failures.
An outreach engine of 13 scripts, each with an offline self-test, found 10,459 businesses on Google Maps across the province of Alicante, kept 9,701 after removing public bodies, chains and duplicates, scored every one, and produced a call list of 5,142 and 362 businesses eligible for email. Sending is gated by a partner's approval.
A legal base on disk: 14 laws and 2,103 articles from the official gazette's open data, with a rule that nothing is said about a law without an opened, cited article.
A team panel of about 17,200 lines of Python on the studio's own server, where Claude runs real jobs with cost tracking and a Stop button.
How the graph works
Five questions
Does the site exist? What changes (data, words, photo, section, design, Google)? Does the layout change? Was the content already supplied? Where else does the old value appear?
Short routes
For data, words, photos and sections: no research, no design director, and a review only when the layout changes or a check fails.
Full round
For design and new sites: research, media and design direction in parallel, three first-screen prototypes, build and copy in parallel, 15 automated checks and one final review.
Specialised by deliverable
SEO is split into three agents (the page, AI search answers and the Google profile) instead of one per stage.
Figure: the routing graph (Obsidian canvas, in Spanish): the request and the state on disk enter a router, seven routes, and the nodes shared by all routes. One town name and one client folder name are covered.
A system that improves itself
Every review feeds the system, so nobody has to repeat an instruction. The partner's literal words are stored first, in their own language, as evidence. They are translated into a concrete element; if a remark such as “this looks AI-made” stays ambiguous, the system asks instead of guessing. It then checks whether the point was already made. If it is new, a short rule is written with author and date, only in the rulebooks of the agents it applies to. If it is a repeat, no second rule is written: the existing one moves up a level, from document to checklist, from checklist to script, from script to a hard block. Since August every repeated rule must name the script that enforces it, and each rulebook is capped at 60 rules, so a new rule displaces an old one instead of piling up.
Quality control
15 automated checks run before anyone sees a site. One measures the first phone screen in real pixels, and it is validated in both directions: it passes the sites the partners approved and fails the ones they rejected. Each check is annotated with the complaint that created it.
Automations
Workflows on a self-hosted n8n server. The restaurant booking flow is live: a request reaches the owner on Telegram, they accept or decline from their phone, and the guest gets a confirmation and a reminder. A waiting list for freed tables and a next-day review request run beside it; their automated verifier ran 453, 148 and 56 checks with 0 failures. Five more flows for dental clinics are deployed, waiting for the messaging provider's credential.
Figure: the n8n editor with the restaurant booking automation and its related workflows (webhook, branching, Telegram and email nodes).
Brand and content
A brand guide and an organic social pack produced with AI, now in review: 8 carousel sets with 102 slides, 2 finished reels, 3 produced ad videos, and 22 video files and 203 images in the marketing folder.
Products and systems of my own
AStar
June 2026 – present
Founder
In development · private demo planned for December 2026 · no public link yet
An AI exam coach for Edexcel IAL Business and Economics. It marks answers, sets questions and coaches revision using the exam board's real papers, mark schemes and examiner reports.
Next.js
TypeScript
Claude API
Supabase
PostgreSQL + pgvector
Embeddings
15 AI skills
Context
Exams reward applying theory to current cases and answering the way the examiners expect. A general chatbot marks without seeing the mark scheme, so its marks are hard to trust. The first version of AStar's agents read 17 hand-written notes and none of the real papers.
Solution
A vector knowledge base of the real papers, mark schemes, examiner reports and textbooks, retrieved per question. There is one examiner and one question setter per subject, each setter checked by a scheme checker, plus a study coach, a news tutor, a diagram agent and a syllabus linker. Every agent cites what it was given, and marking is done against that question's own mark scheme. A calibration layer moves the examiner's mark toward what real examiners gave similar answers.
Results
Within 1 mark of the real examiner on 88% of 33 other students' answers in the 3 November test (82% after the final calibration step)
Within 1 mark of the real examiner on 70% of 30 answers it had never seen (1 November test)
33% closer to the examiner than plain Claude on the same answers
2,470 real exam questions, each with its mark scheme entry
Security review signed off on 2 November 2026 with no open items
By the numbers
About 85,500 lines of code in 627 files and 606 commits since 13 June 2026, counted on 3 November.
27 pages, 41 server routes, 15 specialist AI agents and 18 database migrations, with row-level security on all 33 tables and views.
A knowledge base built from the exam board's own material: 586 documents, 2,470 past-paper questions each with its mark scheme entry, 8,309 examiner insights and 1,320 marking rules taken from examiner reports, and 681 real answers marked by Pearson examiners kept as test material.
167 topic notes, one for every specification point of Edexcel International A-level Business and Economics, written from the specification, mark schemes and examiner reports and then fact-checked (in the Economics round, 111 claims checked and 26 fixed), plus 160 glossary terms and 643 past-paper figures catalogued.
140 diagrams across 36 types drawn by code, not by the AI, each checked for overlaps on laptop and phone and for correct economics. The diagram agent picked and drew the right one 30 of 30 times, in 1.4 seconds at the median.
A handwriting scan that read 97.4% of 3,950 handwritten words correctly and found 33 of 33 answers across 3 papers.
A security review of 8 areas before going online, with every check OK or fixed. 175 security checks pass, 116 live attacks using only the public key were all refused, and no secret key appears in 581 commits. It found and closed real holes: a route that gave free unlimited AI, an invite code that opened unlimited accounts, and 20 simultaneous calls that slipped past a limit. Two fixes were deliberately re-opened and the tests failed both times.
Tests re-run on 3 November, all green: 798 diagram tests, 28 knowledge-pipeline test files, 57 app test files and 130 test files in all, using stand-in models so they cost nothing.
Blind checks of the AI's own work: story-to-topic tagging 0 wrong of 45 (31 of 45 were wrong or incomplete before), the question setter passed 24 of 24 after its own mark-scheme checkers, and the coach attached 1,508 of 1,508 questions to their own unit.
Measured accuracy
The test set is 30 real exam answers that Pearson Edexcel examiners had marked. AStar had never seen them and nothing was tuned on them. Plain Claude is Claude Sonnet 5.5 given the question, the real mark scheme and the answer. The gap is the difference between the program's mark and the examiner's mark.
AStar
Plain Claude
Within 1 mark of the examiner
70%
40%
Average gap, all 30 answers
1.5 marks
2.2 marks
Average gap, Business (14 answers)
2.3 marks
3.3 marks
Average gap, Economics (16 answers)
0.8 marks
1.3 marks
Measured on 1 November 2026 after calibration. Before calibration AStar was within 1 mark on 40% of the same answers. The target is 90% and AStar is not there yet. The sample is small: on 30 answers one answer moves a percentage by about 3 points. The calibration was fitted on 112 other answers, never on the 30.
Newest test, 3 November 2026
A newer version of the examiner was tested on 33 real exam answers written by other students and marked by Pearson examiners. Before the calibration step it landed within 1 mark of the examiner on 88% of them, within 2 marks on 97%, with an average gap of 0.8 marks. With the calibration step, which is what a student sees, the figures were 82%, 91% and 0.9 marks. A second run on 33 answers read by the app from scanned handwriting, not from typed text, gave 73% before and 67% after calibration, an average gap of 1.0 and 1.2 marks. Both sets are small and are not the held-back 30 above, so I report them next to it, not instead of it. The target is still 90% on answers the examiner has never seen.
Before calibration
With calibration
Within 1 mark (33 answers)
88%
82%
Within 2 marks (33 answers)
97%
91%
Exact mark (33 answers)
39%
42%
Average gap (33 answers)
0.8 marks
0.9 marks
Within 1 mark (scanned handwriting, 33 answers)
73%
67%
Source: the test results files of 3 November 2026 in the AStar metrics file, copied as they stand. The marks compared against are the ones Pearson examiners gave on the returned scripts.
The knowledge base
Counted from the database on 2 November 2026: 586 documents (188 past papers, 186 mark schemes, 133 examiner reports, grade boundaries and specifications), 2,470 past-paper questions, 681 real student answers with the examiner's mark, 8,309 examiner insights and 1,320 marking rules taken from the reports, 3,098 textbook pieces from two free textbooks, 205 syllabus topics and 36 diagram types.
How it works
Ingestion
PDFs are converted to text, with OCR for scans, and a script copies the board's exact words into cards. Claude's own judgement (topic tags, command words) is kept in separate files so copied and interpreted text never mix.
Verification
A checker proves every quote word for word against its source. A fake quote planted on purpose proves the checker can fail, and the commit helper refuses to save while a check fails.
Retrieval
Search filters first by specification, unit, marks, command word and topic, then ranks by meaning and word match. If fewer than two questions match, it relaxes the filters one at a time. Mark schemes and level grids are fetched by exact identifier, not by search.
Traceability
Every piece carries an identifier, the agent cites it, the server checks the citation against what was really sent, and the screen shows “Marked against” with the source.
Security
A written review, signed off on 2 November 2026: size limits on every model call, protection against prompt injection on every agent, request limits, private storage for the papers and one account per invite code.
Figure: the Study Room shows a real past question with its extract and the examiner's tips.Figure: the examiner marks an answer 6 out of 8, with what earned marks, what to fix, and the mark for each assessment objective. The account is a demo user.
Figure: the AStar home screen.Figure: a news story linked to the syllabus.
Figure: the study coach answers a revision question and keeps a memory of the student.Figure: a diagram page with Learn, Draw and Describe tabs and a step-by-step drawing guide.
AStar is not used by real students yet. The demo will be private and by invite code, so the real cost and quality per student can be measured before any launch. Plans for later: more exam boards and subjects, accounts and payments, and permission from the boards for their material before anything is sold.
Personal agent system
2026 · in daily use
Architect and daily user
A working environment in which one orchestrator plans, one agent per project executes, and an independent reviewer judges the result.
Claude Code
Python
Obsidian
Hooks
Scheduled tasks
11 projects
22 agents
24 skills
Context
Working through a chat does not scale. Every conversation starts from zero, decisions are lost, and whoever executes ends up approving its own work.
Solution
Separate roles. The orchestrator writes orders with a goal, context, constraints and a definition of done. One executor agent per project does the work. A read-only reviewer judges it against that project's written standard and decides whether another round is needed. Each project has a plan file that is updated in the same pass as the work, and my own corrections become standards the reviewers apply.
Results
Autonomous work in loops of up to 5 rounds
11 hook scripts, some of them hard gates that cannot be skipped
Every unattended run can be undone
22 helper scripts with 15 test files, each check proven to fail on a planted error
By the numbers
22 agents: 11 builders and 11 read-only reviewers, one pair for each of 11 live projects. The reviewers can only read, by design, so they cannot fix what they judge.
About 35,000 lines of Python in 139 files: hooks, scripts and two dashboards, counted on 3 November.
215 seeded test cases pass across 13 of 15 suites (the other 2 test the hooks of a retired project). 77 of them are proven by deleting the check they test and watching them fail.
The brain checks itself against the disk: 17 checks OK, 0 broken, 0 uncheckable on the last run.
416 Claude Code sessions logged automatically over 84 days between 15 July and 3 November 2026, with secrets redacted from every log.
184 rule changes logged by the hook that makes every change of a rule reach every instruction file, from 30 September to 3 November.
A dashboard of 12 views and 35 routes in about 4,200 lines of plain Python with no outside packages, built in four rounds on 2 November. It syncs with Google Calendar every 10 minutes and runs a queued task in the background within 20 seconds, with an undo.
3 scheduled tasks running on their own: a daily research scout, a nightly newspaper and a Sunday review.
Figure: the whole system: capture, ideas, projects, reading and automatic execution. Exact copy of the Obsidian canvas.
Technical detail
verify-live.py compares what the system declares with what is on disk and returns OK, BROKEN or UNCHECKABLE. Uncheckable is never counted as a pass.
Rules that get broken are promoted, not rewritten: from a document to a checklist, to a check that fails the round, to a hard gate. Hard gates include one that protects real employee records and one that stops AI from writing the fields that are mine alone.
A security filter refuses any secret key before it reaches disk, using 20 recognised key shapes, and also redacts keys from the session logs.
A write-shield saves the original of every file an unattended run touches, so the whole run can be undone with one click.
A hook stops a turn from ending when a project's plan has not been updated after the work, and another reaches every instruction file whenever I change a rule.
A fix skill researches how real people solved a problem on forums, GitHub and video comments, scores each fix by independent confirmations, and tries the free ones itself.
My dashboard
A web dashboard I built on 2 November 2026 in four rounds, in plain Python with no framework. It shows my day, my projects with their plans, a calendar synced with Google Calendar, the research finds waiting for a yes or a no, a knowledge graph, and an autopilot that takes one queued task at a time and runs it in the background with an undo. Every write is one validated line in a file the system already defines, backed up first. The research view lists the tools the scout finds without installing them, and tools with no counted need wait until their condition happens.
Figure: the dashboard's knowledge graph: my ideas and what I have read as dots, projects in orange, dashed lines where a reading note helps a project. EconNews is AStar's earlier name; one note title that names a third party is covered.Figure: the scout's tools view. Tools it finds are only listed, with a licence and cost note, and I choose Install it or No. Those that show no counted need wait under “Waiting for a reason” until their condition happens. Rows that mention prices or the old project name are hidden.
Reading system
2026 · in daily use
Architect and daily user
A pipeline that turns what I read into knowledge and connects it to the projects it helps. A daily researcher and a nightly newspaper run on top of it.
Claude Code skills
Python
TF-IDF
Scheduled tasks
152 sources
65 research notes
Context
Saved links rarely reach the project where they would be useful.
Solution
Literal extraction of the source, then notes distilled by idea. A bridge scores every note against each project's open questions with TF-IDF, so words that appear everywhere, like “agent” or “model”, weigh almost nothing and specific terms like “duckdb” decide. Above 0.25 a link is strong, from 0.12 to 0.25 it is worth a look, and below that it is dropped. A judging step then reads the note and the project and creates the link only if it gives the project something usable, with a maximum of three projects per note.
Results
152 sources kept verbatim and distilled into notes, plus 65 research notes written for the projects
Failed extractions are recorded as failed, never reconstructed
A daily researcher that searches only inside filters I write, and refuses duplicates and anything over its caps
A nightly newspaper: 18 editions since 14 October 2026
By the numbers
152 sources ingested over 42 days between 16 July and 3 November 2026: 104 filed, 16 followed automatically from links inside them, 2 recorded as failed rather than invented.
94 distilled notes (65 research notes written by the daily scout, 23 on the reading desk and 6 on the shelf) and 17 weekly digests.
154 bridges between a note and a project's open question: 84 acted on, 62 rejected and never suggested again, 141 judged by Claude rather than by hand.
A daily research scout of 2,071 lines with 47 seeded test cases, each one shown to fail when its check is switched off, and an intake of two gates that asks whether the brain already has a tool and what pain it removes, with a number.
A "fix" skill that searches 218 places in 29 topics where real people solved a problem, and scores each fix by independent confirmations.
An interactive newspaper written overnight by a scheduled agent: 18 dated editions with 265 stories between 14 October and 3 November.
Figure: from link to knowledge, and from there to the project. Exact copy of the Obsidian canvas.
Bridge strength, with an example
A note about DuckDB scored 0.469 against the forecasting project because it answered one of its open questions: where to store numeric data. Today DuckDB is that project's database.
The researcher and the newspaper
Every morning a scheduled researcher looks for tools, techniques, data and answers that would help each project, guided by one line per project. Tools it finds are only listed, never installed, and each one has to pass two gates first: it must beat what I already have, and it must remove a pain I can count in my own logs. Every night another scheduled task writes a white-page broadsheet on economics, business and politics, with a line linking each story to my exam topics, glossary words, a “explain it simply” button and questions that the system answers from the sources.
Content Engine
August 2026 – present
Architect
A platform for producing AI-generated content with its own dashboard: from a request to a publishable piece, with every step visible, approvable and reproducible.
Python
Image, video and voice model APIs
ffmpeg
Custom node editor
Custom web dashboard
Headless Claude
6 pipelines
6 AI characters
Context
Producing generated content at scale needs three things at once: characters whose face and body never change, images and video that look filmed by a real person, and strict control of spending and quality. A loose image generator offers none of them.
Solution
An engine with adapters to image, video and voice models, deterministic assembly and a log of every call, and a dashboard of its own. Each task is a run with its history, and its pipeline opens as a node editor. Runs that cost money are prepared and then stop until I approve them with the exact price on screen.
Results
173 carousels in 11 formats produced for advertising (bank counted on 3 November 2026)
6 consistent AI characters built with the same sequence
6 production pipelines, each opening as a full editor
44 runs recorded with their images, settings and steps
Paid steps cannot run without my approval
Used for TikTok Shop content and realistic ads for brands
By the numbers
About 113,000 lines of Python: the engine (60,300 lines in 78 files, 17,500 of them tests), the pipelines (28,100 lines), the tools (9,300 lines) and the dashboard server (15,500 lines) with a 10,666-line single-page app.
76 model entries across three providers: stills, edits, upscalers, text to speech, lip sync, avatars, sound effects and 26 video models.
133 dashboard routes, 7 views and 6 pipelines that each open as a full editor, with 28 picture styles in the promo pack and 4 video formats.
1,325 model calls recorded in the ledger between 1 September and 3 November across 48 models, each with its time, model, purpose and the piece it belonged to.
9 AI characters built, 3 current and 6 archived, each a re-runnable recipe in a character file.
173 carousels with 921 slides in 11 formats, 8 of them drawn by code in a single day (9 October) with a 37-check test that passed, including a test proving that the company's own template kit was never written to.
A measured fix for identity drift: with 5 reference pictures a batch kept 12 of 19 (63%); on the same failed photos, 3 reference pictures kept 5 of 5 (a small sample of 5). The bar for a batch is 90%.
A model comparison of 27 images across 9 models and 3 scenes (skin, full figure, mirror selfie), 27 of 30 runs successful, with an Apple Vision face checker that flags a hard source photo before a picture is made.
The work I did with it
In September and October 2026 I used the engine for a company that paid creators to publish advertising carousels on short-video social networks. I built a system to generate consistent AI characters, whose face and body stay the same in every picture, and I standardised it so that carousels could be produced in volume for advertising. What the standardisation consisted of:
Characters: six AI characters, each built on the same sequence (a described person, proposed faces, one chosen, every angle and body derived from that face). Every new picture is then an edit of a real reference photo, so framing and light look like something a person filmed.
Formats: every carousel format became a fixed template, 11 formats in all, and 8 of them were drawn with the slide renderers from the company's own creator kit so the output matched what the company published.
Weekly pipeline: one plan of production lines per week (93 lines in the second weekly plan) turned into carousels by one pipeline, with a bank organised by format where each carousel is stored once and reused only under written rules.
Checks: a short daily report, a script that checks an iteration changes only a couple of words, and a rule that a character's board shows everything that character has, enforced by a hook that stops the work otherwise.
Output: 173 carousels in 11 formats in the bank, counted on 3 November 2026.
The two workflows as I used them
Figure: the character workflow I used for the advertising work, as the pipeline editor showed it: a description, three face prompts written by Claude, four generated faces with one chosen, six “before” bodies and three “after” bodies, and a 14 + 14 reference sheet with every angle before and after. Each picture can be picked, redone, edited or rejected with a note. The character's name is covered.Figure: the weekly carousel pipeline. The character and the company's weekly document go in; a Claude session reads the document and writes the week's plan; one run builds every carousel from saved photos and the character's pictures; a final check lists what is pending. This week: 35 carousels, 84 of 84 photo slides with a saved picture. Names are covered.Figure: the board of the first character, as the editor showed it. On the left, his generation: a seed prompt, four faces with one chosen, three bodies, and three fit bodies with their views. On the right, five finished carousels, every slide an edit of those bases, each with its caption and its count of pictures made. Slides that name the company and account handles are hidden, so some rows show fewer slides.
All of it is now part of the engine: the characters, the formats, the weekly pipeline and the checks.
The plan
The engine now serves two directions. First, AI models for businesses: consistent AI characters used as a brand's own models in advertising, produced with the same standardised pipeline. Second, TikTok Shop content: promo packs with the product locked, and videos, made and posted by a person I train. The next technical step is video: I chose a video model by eye from a side-by-side reel of candidates, and the next step is a short test of whether it accepts the character's face, speaks natural Spanish from Spain and looks filmed, before any volume. The promo-pack and video pipelines are built and tested, and nothing paid runs without my approval.
The dashboard
Runs
Every task is a card with its pipeline, pictures and videos, settings and steps. A run can be repeated, opened in its folder or downloaded whole. Runs waiting for approval come first.
Pipeline editor
Each step is a node with its settings, model and run button. On every picture I can pick it, redo it, edit the prompt and redo, or reject it with a note.
Realism loop
Each ✓ or ✗ with its note is stored, dated, in the project's standards, and every prompt the engine writes afterwards reads them. The system learns from each correction.
Instructions
A text box that launches Claude in the background. It shows its task list advancing, leaves a note of what it did and can be undone. It cannot spend: a paid step runs only with my approval.
Figure: the pipeline catalogue. Each one opens as a full editor.
Production pipelines
TikTok Shop video (12 steps)
Product, character, format and market, reference video, a script with three hooks, first frames generated from real photos, voice, clips, lip sync, assembly, a check and the final video.
Character (8 steps)
Description, three face proposals, eight angles of the chosen face, three body builds to choose from, front, three-quarter and back body sheets, and optional training.
Promo pack (9 steps)
From a product's photos, a character and a link, it makes posts, carousels and videos with the product locked so it does not change from one image to the next.
Image-to-image batch
Each picture in a character's bank starts from a real photo and only the identity changes, so framing and light are those of a real photo. A check measures the share of each batch that keeps the identity and requires 90%.
Model comparison and video from a picture
Two smaller pipelines for testing image and video models side by side before committing to one.
A workflow in the editor
Figure: one promo-pack workflow as the pipeline editor shows it: the character, the product with its photos, the brief and the chosen post styles, the voice, the models, the look, the output folder, a single priced click and the pack of posts to review. The prices are the engine's estimates, shown before any paid step is approved. The product photos are blurred.
Bet-Forecaster
July – September 2026 · with a partner
Co-builder
Engine built · set aside until it is proven
A football forecasting platform that combines historical data, live odds and statistical models to look for pricing errors by bookmakers. It never places bets.
Python
DuckDB
Football data APIs
Live odds API
Claude Code
27 tools
175 tests
Context
Bookmakers set their prices with teams of analysts. Finding a real edge takes more data, a reproducible model and a method that does not fool itself with lucky hits.
Solution
A platform connected to football data sources and a live-odds API, with an analytical database in DuckDB, a calibrated Poisson goals model and a scanner that reviews upcoming matches and flags prices above their fair value. The language model orchestrates and explains; all the calculations are deterministic.
Results
94,511 matches from 25 divisions, 2012–2026
A rule tested on six unseen seasons beat the closing price on 82.7% of its selections
27 tools and 175 passing tests
A six-view dashboard with on-demand scanning
By the numbers
94,511 matches in 25 divisions (22 European plus Argentina, USA and Brazil) over 27 seasons and 676 clubs, with closing odds on 93,199 of them and expected-goals data on 19,649.
31 Python tools in 9,802 lines with a single pinned dependency, and 12 tools with offline self-tests: 208 checks pass with 0 failures.
13 hypotheses, each with its kill condition written before any result, and pre-registration files committed before the code ran in rounds 4 to 7.
Honest negative results, stated plainly: a Poisson goals model lost to the closing line on 1,900 never-tuned La Liga matches (log-loss 0.995 against 0.968), and with a calibration layer the market still won the match-result forecast in all 22 divisions.
One idea with a measured edge, reported with its caveats: on a window frozen before selection it had 234 bets, a closing-line value of +6.64% and t = 2.17, positive in all 4 seasons, but it does not survive correction for 22 simultaneous tests.
Technical detail
Data
Results, statistics and opening and closing prices from several bookmakers since 2012; live prices captured by API under a call budget; dated news per match. Every row stores its source and ingestion date, and the whole database rebuilds from one script.
DuckDB
54 columns per match, 676 teams, queries in about 12 ms with no server. Design rule: numbers go to the database, text goes to search.
Modelling
Three methods to remove the margin from the reference price, a Poisson goals model with a calibration layer, bootstrap intervals from 400 resamples, and same-match combinations priced from the joint score matrix.
Method
Four rounds of backtests with hypotheses registered before testing, out-of-sample validation, and tracking against the closing price, the measure professionals use instead of hit rate. Three rounds were honest negatives; the surviving hypothesis only worked in thin markets.
Risk
A 60% minimum probability, an explicit “no bet” when nothing passes it, and no automatic placing of bets.
Figure: the two approaches evaluated: detecting bookmaker errors against predicting on my own. Exact copy of the project canvas.Figure: the division of work between the language model, DuckDB and search. Exact copy of the project canvas.
Other work with AI
Websites and a staff time-clock for a local retailer
A bilingual website for a European-foods supermarket and the staff time-clock ledger that Spanish law requires. Both are built and not yet live; the employee records are protected by a hard gate that no agent can write through.
AI for a family real-estate agency
Research into where AI can help a family-run agency win more listings and sell more: lead capture, listing copy and ad logic. Under way; nothing is live yet.
Revision tools for my own exams
Revision notes, diagrams and questions written with Claude from the official specifications, and an interactive revision book. Marks are checked blind against official mark schemes.
Digital design coursework
A fictional menswear brand identity for a graphic communication course. Final designs are made in Adobe programs through an AI connector, every step is logged, and every AI-generated image is credited with its exact prompt.
Second-brain systems for others
A delivery playbook for building tailored second-brain systems on the pattern of my own environment. Designed; no clients yet.
Education and results
Economics, Pearson Edexcel International A-level, AS (June 2026)
195/200, grade A.
Business, Pearson Edexcel International A-level, AS (June 2026)
157/200, grade B.
Spanish, Pearson Edexcel International A-level (June 2026)
366/400, grade A.
IGCSE (June 2025)
Pearson: English Language 8 · Business 7 · Mathematics 7 · English Literature 6. Cambridge: Literature in Spanish B.
Summary
In the last months I have moved from using AI to designing systems that work with it reliably: a studio that delivers websites and automations to real clients, a working environment that plans, executes and reviews itself, and products of my own with data, statistics and agents.
What I bring to a team is the combination of three things: understanding a problem and turning it into a plan with clear success criteria, building the system that solves it, and making sure, with tests and not impressions, that it works and keeps working. I report my numbers with their sample size, including the ones that fall short.
