# Matt Pyle — Full Content Export Director of Growth at Temporal Technologies. Growth marketer and hobbyist builder. This exports every published article and build plus the current public scorecard snapshot from mattpyle.com, generated at build time from the same content that backs the live site. See https://www.mattpyle.com/agents.md for citation guidance. --- ## WebMCP tools (experimental) The live pages register four WebMCP tools on document.modelContext. Three are read-only — describe_site, get_recent_writing, and search_content. One is a write tool: set_appearance, which switches this site between its modern and retro appearances. Its write is client-local, storing a preference in the calling browser's own localStorage; it changes no server state and affects no other visitor. (navigator.modelContext is the same object as document.modelContext, not a deprecated fallback — measured on Chrome 150, 2026-07-17.) They are callable only by in-browser agents that implement WebMCP; a doc-reading agent cannot invoke them from this file. Machine-readable: https://www.mattpyle.com/webmcp/tools.json is the tool manifest (names, descriptions, input schemas, example calls), generated from the live tool objects. https://www.mattpyle.com/webmcp/index.json is the static content index the tools read — the same author entity, section map, writing list, and builds list exported below — and you can fetch it directly. https://www.mattpyle.com/webmcp is the human-facing page, with the per-tool detail and the current state of the standard. --- ## Scorecard URL: https://www.mattpyle.com/scorecard Verified: 2026-07-25 Scope: 19 live pages Tools: Lighthouse 13.4, axe-core 4.12 - Accessibility: 100 / 100 (Pass) — The lowest Lighthouse accessibility score across 19 tested pages. No automated WCAG violations. - Performance: 99 / 100 (Pass) — The lowest Lighthouse performance score across 19 tested pages. - SEO: 100 / 100 (Pass) — The lowest Lighthouse SEO score across 19 tested pages. - Agentic Browsing: 4 / 4 (Pass) — 4 of 4 agent checks pass: accessibility tree, WebMCP, layout stability, llms.txt. --- ## Writing ### Hello, World! Or, this post is a lie. URL: https://www.mattpyle.com/writing/hello-world Markdown: https://www.mattpyle.com/writing/hello-world.md Date: 2026-07-18 Tags: agents, temporal, tech Testing Temporal workflows, deterministic standards, and agentic AI to build an editor for my website I think I committed a cardinal sin. A "Hello, World!" post as the second published entry feels...off yet, here we are. ## Why this site exists This website has two primary purposes: 1. Encourage me to write more about the topics I care about and find interesting 2. Learn and experiment with evolving website trends and development practices in the era of AI Those are the two I'll tell everyone but there's a reason this website is public under this domain name https://www.mattpyle.com. I'm looking to improve my personal brand. I've owned this domain since 2015. For a while it went nowhere, then, I did a lazy thing and, forwarded it my LinkedIn. Lame! This gave me the excuse of just leaving it. I've never been good at self-promotion and advocacy so I'm utilising what I do find interesting such as playing, building, tinkering, and experimenting, and using that as a forcing-function to create, and write about, this very site, out in the open. *side note: Before this domain, I owned `matthewpyle.com` but the only people who call me Matthew are the government and my mum when I've done something wrong.* ## Building in the open One of the goals of this website is to be as transparent as possible, while remaining safe and secure. The website codebase is available to view on my [Github profile](https://github.com/mattpyle/mattpyle.com-website), verified site test scores are published on the [scorecard](/scorecard), there's a [changelog](/changelog) where details on major site changes and features are shared. This is just the start. As can be read on the changelog, a lot of experimental features, such as adding a [WebMCP surface](/changelog/webmcp-tools), have been added in the short time since this site went live. Those features and changes are all in the pursuit of learning (something I enjoy) and will be written and shared here (something I'm learning to enjoy!). There are a few things currently .gitignored. Aside from environment variables, api keys, and config that has no reason to be public I'm currently not sharing: - Claude.md - *for Claude* - AGENTS.md - *for Codex* - Backlog.md - An evolving set of ideas for website features, builds, and content - Learnings.md - A quick file to capture learnings from building. *note to self: this is actually looking outdated* - Scoreboard.md - This captures the output and scores from regular performance, a11y, seo, and agentic browsing checks. Now available publicly on the [scorecard](/scorecard) - `/steward` - The reason this post exists *...more on that later* ### This post is a test Ignore the title. This is not your typical "Hello, World!" article, made obvious by this not being the very first post. Truthfully, I'm building something I think is cool. My AI coding assistants have essentially forced me to write this post, in my own writing style, prose, grammar, *Britishisms*, and including my own mistakes in order to test the prototype of Steward. ## Steward - Demonstrating Temporal & agentic workflows on this website ### What is Steward? Steward is an editorial agent that owns the path from a draft article (`draft: true`) to published for posts on this website, mattpyle.com. It is implemented as Temporal workflows running against a local [Temporal](https://temporal.io) dev server, with a worker whose activities review, score, and gate a post; wait durably for a human verdict; and then execute the publish mechanics end-to-end, including live verification against the deployed origin. ### Why does Steward exist? The thesis being demonstrated is: **the difference between an AI toy and an AI coworker is durable execution, observability, and a human-in-the-loop protocol.** The Temporal workflow history is the agent's audit log. However, I already outlined this website's purposes as learning and building in the open. Here, I'm looking to learn how developers (and even non-devs, such as *vibe-coders*) build with Temporal and how agentic AI workflows are launched and used in production-like environments. ### Testing Temporal and agents As I alluded to, this post is a test. I currently have a local Temporal dev server running, using the [Typescript SDK](https://github.com/temporalio/sdk-typescript), and the [Temporal Developer skill](https://github.com/temporalio/skill-temporal-developer). So far, I have spent the exorbitant fee of $0.08 USD in Anthropic API usage. Then, both Opus in Claude Code and Fable in Claude Chat told me **"You need to write more in order for us to test this properly"**. ## The tech stack Right now, I am *phoning in* in the rest of this post. I'm losing a bit of steam and, dear reader, you can be assured that this will be much better quality when it meets your eyes, all thanks to excessive amounts of coffee, the gentle nudges of my coding assistants, and Steward. However, the tech stack and tooling for this website is as follows: - [Astro 7](https://astro.build/blog/astro-7/) - a lightweight framework for content-driven sites, all content written in Markdown - Hosted on [Vercel](https://vercel.com) hobby tier for now (I'm not that popular!) - Using Claude Code and Codex to build - [WebMCP](https://github.com/webmachinelearning/webmcp) - This site is enrolled in the WebMCP Origin Trial and, if you so desire, you can test out the functionality! - Axe - The repo has built in Github actions that run [axe-core accessibility](https://github.com/mattpyle/mattpyle.com-website/actions) checks on production builds - [CSpell](https://cspell.org/) - Since this is all markdown, I'm writing this very article in VS Code which surfaced the need to check my spelling. Vale does that, and is being built into Steward. By the time this post goes live, I hope to say: - Temporal server, workers, and workflows - [Vale](https://vale.sh/) is being used to check the quality of my writing mechanically and deterministically. It's important to note one thing about Vale, CSpell, and other deterministic checks on this website. One part of Steward is to create a learning loop. Where the Editor agent finds issues that could have been diagnosed mechanically, it is captured as a learning and implemented against. This will both save costs and resources, but also allow the agent to focus on what it will do best. ## How this site is built I'm currently using both Claude and ChatGPT to build this website. It's a mix of all their offerings — Design, CLI, Codex, Desktop apps. I tend to lean towards designing a plan with the higher-intelligence (and higher-cost) frontier models, implementing incrementally with lower-effort and lower-priced models, and continuously re-reviewing with the planners. However, competition is creating a healthy environment for the end-users right now and frequent usage resets, increased limits, and promotional offers are allowing me to try different things. Using multiple LLM/AI tool stacks in collaboration is a learning experience and I soon hope to try others such as Kimi K3 and GLM 5.2. ## What's next? Well, I give this post to Steward. Then... I tell you what happened. --- ### Accessibility, AI, and testing with screen readers URL: https://www.mattpyle.com/writing/accessibility-and-ai Markdown: https://www.mattpyle.com/writing/accessibility-and-ai.md Date: 2026-07-13 Tags: accessibility, agents, measurement AI built this site. Every automated tool gave it top marks. Then I installed a screen reader for the first time, spent an evening fumbling with it, and heard what my site actually sounds like. Lighthouse 13.3, launched in May 2026, shipped an [**Agentic Browsing**](https://developer.chrome.com/docs/lighthouse/agentic-browsing/scoring) audit category by default. As the standards for the agentic web are still emerging, the Agentic Browsing category gives binary pass/fail signals instead of a 1-100 scale like other categories, and is one of many emerging tools prompting us to ask the question: *can an AI agent actually read my site?*. The past 12 months have brought an interesting new spotlight on a11y practices. The accessibility tree, which acts as the semantic bridge between website code and assistive technologies, is now being [parsed by AI agents alongside the raw HTML and screenshots](https://www.accessibility.works/blog/value-of-accessibility-compliance-for-aeo-in-agentic-web-era/). Clean, semantic trees allow agents to easily find valuable buttons and fields such as "add to cart" or "sign up" without relying on fragile screenshots or bloated code. Generic audits and checklists give you a false sense of security and accomplishment, the same failure mode as every generic SEO audit checklist: **scan the thing, change the thing, get a green check, feel good**. This website exists to build, play, experiment, and learn so I ran an accessibility audit against this website and learned that in order to truly evaluate your accessibility experience, you must experience it yourself. ## a11y is for everyone ![The Simpsons meme with Milhouse telling Bart "Remember A11y? Now it's back! In bot form."](../../assets/a11y-bot-form.png) I could write anything in the alt attribute for the above image and the build would pass. An automated accessibility testing tool would fail me for omitting an alt tag, but it'd happily pass a really terrible one. My score would go up. A11y (or, accessibility) has been a passion of mine for a while. Consider it a sign of my growing age, but I still remember my life before the Internet and the immediate life-changing impact it had and still has. Ensuring that every human has an equitable and safe experience online to unlock that same impact is a basic requirement that is often shamefully overlooked. Building this site has been a hobby project. Equal parts: write more; be more visible; build and have fun. As part of this, I want to use this website as a testbed for all things online - whether it's accessibility, SEO, AEO, performance. Getting hands-on with my own brand for the things I work with my team on at work. Experiment, fail, learn, and share those learnings transparently. Will the bot revolution bring fair online experiences for all humans? We'll see. ## What the code review caught and missed The filter buttons on my writing index communicate their active state through a CSS class and nothing else. Nothing in the markup says which filter is on. A sighted human sees the highlighted pill and knows which filter is applied. The accessibility tree sees **multiple identical, indistinguishable buttons.** A screen reader user, and an agent, cannot tell which filter is active, or that clicking one did anything at all. However, `/about` had no `

`. At all. This is one of those things that has appeared in my professional life when auditing website best practices. Apparently it's as easy for a bot to skip as it is for the human who wrote the page. The Lighthouse accessibility-tree audit and my own checklist, built from years of experience, somehow completely missed it. Who would miss a h1? Honestly? Thankfully, having multiple instruments paid off as axe caught it instantly. I'd explicitly worried about the *opposite* problem, writing a note in my SEO checklist to "confirm no page renders two `h1`s". ## How 'aria-pressed' works I asked my Coding Assistant to fix the filter: "Fix the issue, maximum effort, make no mistakes". `aria-pressed` was added to each pill — `true` on the active one, `false` on the rest. axe reported zero violations. Lighthouse stayed at 100. Agentic Browsing stayed at 3/3 (Accessibility tree is well-formed, Cumulative Layout Shift passes, and llms.txt follows recommendations). Then I read the spec properly. `aria-pressed` describes a **toggle button** — an independent on/off state. Press it once, it's on; press it again, it's off. My filters on my blog index page aren't that. They're **mutually exclusive**: clicking `AI` *deselects* `ALL`. Only one is ever active. Announcing "AI, toggle button, pressed" tells you nothing about `ALL` having just switched off, and falsely implies each pill toggles independently. Every automated tool passed it as `aria-pressed` on a `