# Runtime Projects at AI Tinkerers

> Canonical HTML: https://aitinkerers.org/technologies/runtime
> Markdown URL: https://aitinkerers.org/technologies/runtime.md
> Technology record last updated: 2026-02-24T00:27:31Z
> Generated: 2026-09-22T00:32:24Z

The software environment that executes code: it provides core services, manages resources, and acts as the crucial abstraction layer between your program and the operating system.

A Runtime Environment (RTE) is the dedicated platform where a program’s compiled or interpreted code runs, abstracting away the underlying OS and hardware complexities. It handles critical operations: memory allocation (heap and stack), garbage collection, I/O access, and threading. For example, the Java Virtual Machine (JVM) executes Java bytecode, while Node.js and Bun utilize the V8 engine to run JavaScript outside of a browser. This environment ensures cross-platform compatibility and provides the necessary system interfaces (APIs) for your application to function correctly.

- Official technology site: https://developer.mozilla.org/en-US/docs/Glossary/Runtime_environment
- Public AI Tinkerers demos and talks: 10
- Result page: 1 of 1

## Recent Public Talks and Demos

### [Pop the Hood on an AI Agent: Loop Engineering on Open Models](https://raleigh.aitinkerers.org/talks/rsvp_lGEh5nJoRO8)

Back in 2022 I did this the hard way: topic modeling in R on data pulled from the then-free Twitter API, to help a company decide which LMS to invest in based on what users and buyers were actually saying. Now, with agents and loop engineering, I wanted to see if I could build something similar on today's tools, and break down what loop engineering actually is while doing it. So I built a competitor-listening agent you can run weekly. Point it at your product and its rivals and it listens across open platforms, then drafts a brief on where you're winning, losing, and the gaps to attack, on open models with no API keys needed to run it. But the point of the demo is what's inside it. When you use an agent in Claude, Copilot, or OpenAI, a loop is running that you never see. I rebuilt that same loop by hand, on open models, so you can watch every part of what an agent is actually doing under the hood. Live, I'll run it in a Colab and walk the loop step by step: gather from open sources, do the cheap NLP work (sentiment, topic modeling) with free, validated tools, and reserve a single open-model call for the actual reasoning, which is reading the signal and naming the gap. Then it drafts the brief, proposes what to watch next, and I approve to widen the following week's listening. You'll see the code, the guardrails, and the repo (a runnable demo plus a fill-in template). It's a live, Colab-fragile build and I'll embrace the rough edges.

- Event context: AI Tinkerers Raleigh Meetup — August 12, 2026 — 2026-08-12 — Raleigh
- Public talk page: https://raleigh.aitinkerers.org/talks/rsvp_lGEh5nJoRO8

### [Operating an Agentic Homelab with Agent Guides](https://seattle.aitinkerers.org/talks/rsvp_wvjI8VfiuMM)

I built a multi-node homelab with layered, enterprise-grade security (passwordless auth, secrets management, host hardening) and an OpenTofu plus Ansible control plane for infrastructure and deployment. AI agents operate it instead of me clicking through consoles. In order to facilitate rapid iteration and configuration I created a new open-standard data format called Agent Guides, which are open, Skill-compatible markdown runbooks. Provisioning a new LXC, rotating credentials, or updating firewall settings are repetitive over time, but the details drift and some of the APIs have undocumented behavior, so a single prompt is unreliable and a fixed script breaks. Plain wiki runbooks aren't ideal because they go stale as soon as the environment changes. What I wanted was documented procedures an agent can follow but still improvise when it hits something unexpected. The guides for my homelab are executed primarily by agents, whose harness leaves an audit log to review afterwards, so another agent may update the guide automatically instead of rediscovering the same problem the next time.

- Event context: AI Dev Tools Track - Seattle - July 13 — 2026-07-14 — Seattle
- Public talk page: https://seattle.aitinkerers.org/talks/rsvp_wvjI8VfiuMM

### [Does your coding harness actually do anything? Measuring it, fairly.](https://boston.aitinkerers.org/talks/rsvp_bx0CiDi1_uo)

Everyone's bolting "harnesses" onto coding agents — Superpowers, GSD, Agent-Skills, Compound Engineering — but does the scaffolding actually make the model build better software, or just feel better? CodingHarness.xyz is an open eval that pits these frameworks head-to-head: same spec, same model, isolated sandboxes, and an evidence-based rubric (does it meet the PRD? is the code any good?). I'll share the surprising result — an inverse-scaling effect lifted straight from a recent Xiaomi paper and reproduced on real runs: harnesses help most exactly where the base model is weakest, and barely at all where it's already strong. Even better, it's framework-dependent — one framework tracks the curve almost perfectly, another inverts it and only helps strong models. Live demo of the eval studio: watch two frameworks build the same app, stream the agent's work turn-by-turn, and see the marginal-gain scorecard light up green/red. Plus a sneak peek at turning framework competitions into a spectator sport (think FIFA bracket, but for coding agents).

- Event context: AI Tinkerers Boston: GTM Agentic AI Launch — 2026-06-29 — Boston
- Public talk page: https://boston.aitinkerers.org/talks/rsvp_bx0CiDi1_uo

### [Cognitive Cell: Building a Route-Select-Render Control Layer for Workflow AI](https://columbus.aitinkerers.org/talks/rsvp_o1YZyZ3Z09I)

I built Cognitive Cell, a public Python package and HTTP sidecar that sits in front of an LLM and decides whether an input should be recorded, clarified, analyzed, planned, answered directly, or escalated. The accepted v9 stack is router-v4 → selector-v5 → finalizer-v9. I will show the live package, CLI, HTTP sidecar, architecture, traces, evaluation files, and the messy journey from a research prototype to a PyPI package. Live demo elements: - Python package: pip install "cognitive-cell[server]" - CLI: cognitive-cell --event-json ... - HTTP sidecar: cognitive_cell.server.app - /health endpoint - /v1/sidecar endpoint - trace output - evaluation CSV/JSONL artifacts - ablation results

- Event context: AI Tinkerers - Columbus June Meetup — 2026-06-01 — Columbus
- Public talk page: https://columbus.aitinkerers.org/talks/rsvp_o1YZyZ3Z09I

### [Pull-architecture agents: how I forced myself to do growth work](https://valencia.aitinkerers.org/talks/rsvp_-p7b50BEZW0)

A multi-agent system that manufactures pull for the growth work — writing, conference follow-up, CRM hygiene, responding to news — that I'd otherwise skip when product and ops eat my week. Seven agents across five repos, two APIs, and two websites (one fully autonomous), all driven from the only two surfaces I actually live in: my terminal and Mattermost. The demo walks a live pass through the rig: a LinkedIn contact lands in our self-hosted CRM, an article draft gets pushed to a website, a post-conference follow-up gets queued — every action is a curl command an agent emits, with circuit breakers I can tighten in the moment or across the long arc.

- Event context: AI Tinkerers Valencia May Meetup — 2026-05-26 — Valencia
- Public talk page: https://valencia.aitinkerers.org/talks/rsvp_-p7b50BEZW0

### [Cloud-Hosted, Multi-Agent Workspaces (or: Gas Town in the Sky)](https://seattle.aitinkerers.org/talks/rsvp_mVgQoXtoVzE)

A live walkthrough of a multi-agent software development loop in the cloud: Head of Engineering (agent) receives a request from Discord, writes the code, opens a PR, goes to Head of Infra to deploy, and then finally hands the change to Head of QA for review and merge, all without any intervention from the user. The presentation will cover how I created the best way to make easy, configurable, multi-agent workspaces without the infrastructure hassle or security risks of self-hosted solutions. This includes setting up persistent, isolated workspaces, configurable prompts and variables, cross-agent messaging, and deep session analytics, all managed through a custom-built MCP server and my local Claude Code. In addition, throughout the demo I'll share exciting developments I've seen so far in terms of emergent behavior, cross-agent coordination, and workspace management.

- Event context: AI Tinkerers Seattle Meetup: Dev Tools Track — March 9th, 2026 — 2026-03-10 — Seattle
- Public talk page: https://seattle.aitinkerers.org/talks/rsvp_mVgQoXtoVzE

### [GPU-Streaming Omniverse to the Browser Per‑Org Sessions over WebRTC](https://miami.aitinkerers.org/talks/rsvp_Mq1fLtz3A-E)

Live build walkthrough of a prototype that spins up an isolated NVIDIA Omniverse/Kit session per organization, then streams it into a standard web browser via WebRTC. I’ll show the end-to-end flow: request → provision Azure GPU instance → boot the Kit runtime → establish a WebRTC connection → interact in-scene → teardown/cleanup. Focus is on the state machine, orchestration, and the practical failure modes (startup latency, ICE/networking, cleanup).

- Event context: AI Tinkerers Miami Meetup — The 2026 Builder Kickoff — 2026-02-11 — Miami
- Public talk page: https://miami.aitinkerers.org/talks/rsvp_Mq1fLtz3A-E

### [Design → Agentic UI Parity: Verifiable Figma/XD → MCP App UIs using constraint manifests + template registries](https://nyc.aitinkerers.org/talks/rsvp_ISg04Sc9n2Q)

We’ll demo a verifiable pipeline that translates Figma/Adobe XD designs into constraints + tokens + responsive rules, generates interactive MCP App UIs, and produces a design parity report (auditable) that proves the shipped UI honors design intent across breakpoints. What we’re building (technical, grounded) A design-to-agentic-UI system with four primitives: Design ingestion (Figma/XD) Extract design tokens (color, type scale, spacing), component semantics (buttons, cards, nav), and layout intent (grid, alignment, density). Convert to a normalized Design Intent Spec (DIS). Template registry (universal UI templates) A library of parametric templates (layout archetypes + interaction patterns). Templates accept tokens + constraints and output UI code. Constraint manifest (the verification core) A machine-readable manifest that encodes: Layout constraints (grid columns, min/max widths, padding rules, alignment invariants) Responsive rules (breakpoints, reflow behavior, truncation rules, priority ordering) Component contracts (required states, accessibility expectations, interaction affordances) This manifest is the “source of truth” the generator must satisfy. MCP App UI runtime The UI is delivered as an MCP App (interactive UI inside the client) with explicit tool bindings (UI actions → tool calls). The same manifest drives both generation and verification. The verification mechanism (non-brittle parity checks) We’ll show two complementary verification layers that go beyond “apply tokens”: A) Structural / rule-based verification (fast, deterministic) Compile DIS → constraint assertions per breakpoint: e.g., “card grid is 1-col under 640px, 2-col under 1024px, 3-col above” “primary CTA remains above the fold on mobile” “nav collapses into drawer with N max items visible” Verify the generated UI against these assertions by analyzing: template parameters used layout tree structure computed layout properties for each breakpoint (from the rendered DOM snapshot) B) Visual / perceptual verification (tolerant, non-brittle) Render both: design reference (from Figma/XD export frames) generated UI (MCP App UI at the same viewport sizes) Compute similarity using: a perceptual diff (SSIM/LPIPS-style) and bounding-box alignment checks for key components (header, CTA, cards) Output a parity score per breakpoint + annotated diffs. The auditable output (what we’ll “pop the hood” on) A concrete engineering artifact called a Design Parity Report, containing: tokens applied (hashes + versions) template IDs and parameters used constraint manifest version parity scores per breakpoint annotated diffs for any violations remediation hints (“use Template X instead of Y”, “tighten padding constraint at md breakpoint”) This report is logged as an append-only, auditable event alongside the UI artifact, so teams can prove what changed, why it changed, and whether parity improved or regressed over time. What we’ll demo live (5 minutes) Start with a Figma/XD screen (desktop + mobile frames). Ingest → generate interactive MCP App UI. Run the parity checker across 3 breakpoints. Show the Design Parity Report + one intentional failure (e.g., CTA drops below fold on mobile). Fix by changing a constraint or swapping template → re-run → parity passes.

- Event context: Feb Demo Day: How are you turning design into code? (with Baz) — 2026-02-04 — New York City
- Public talk page: https://nyc.aitinkerers.org/talks/rsvp_ISg04Sc9n2Q

### [Human machine](https://seattle.aitinkerers.org/talks/rsvp_cDs_nfJfXZs)

A code editor and runtime to use multiple AIs together to prototype stuff. Code with voice and pen, or make art.

- Event context: AI Tinkerers Seattle - December 2024 Meetup — 2024-12-12 — Seattle
- Public talk page: https://seattle.aitinkerers.org/talks/rsvp_cDs_nfJfXZs

### [Generative UI: Using LLMs to Build Dynamic UI at Runtime](https://seattle.aitinkerers.org/talks/rsvp_KQgxuBn8zPQ)

Demonstrate how the UI can be built dynamically at runtime by the LLM based on the user's query/needs.

- Event context: AI Tinkerers Seattle - August Meetup — 2023-08-09 — Seattle
- Public talk page: https://seattle.aitinkerers.org/talks/rsvp_KQgxuBn8zPQ

## Related Technologies

- [Agent](https://aitinkerers.org/technologies/agent) ([Markdown](https://aitinkerers.org/technologies/agent.md)) — 12 public demos
- [Claude Code](https://aitinkerers.org/technologies/claude-code) ([Markdown](https://aitinkerers.org/technologies/claude-code.md)) — 215 public demos
- [BERT](https://aitinkerers.org/technologies/bert) ([Markdown](https://aitinkerers.org/technologies/bert.md)) — 179 public demos
- [BLOOM](https://aitinkerers.org/technologies/bloom) ([Markdown](https://aitinkerers.org/technologies/bloom.md)) — 115 public demos
- [Docker](https://aitinkerers.org/technologies/docker) ([Markdown](https://aitinkerers.org/technologies/docker.md)) — 147 public demos
- [GPT-3](https://aitinkerers.org/technologies/gpt-3) ([Markdown](https://aitinkerers.org/technologies/gpt-3.md)) — 191 public demos
- [GPT-4](https://aitinkerers.org/technologies/gpt-4) ([Markdown](https://aitinkerers.org/technologies/gpt-4.md)) — 529 public demos
- [Llama-2](https://aitinkerers.org/technologies/llama-2) ([Markdown](https://aitinkerers.org/technologies/llama-2.md)) — 227 public demos
- [MCP](https://aitinkerers.org/technologies/mcp) ([Markdown](https://aitinkerers.org/technologies/mcp.md)) — 129 public demos
- [PaLM 2](https://aitinkerers.org/technologies/palm-2) ([Markdown](https://aitinkerers.org/technologies/palm-2.md)) — 116 public demos
- [Python](https://aitinkerers.org/technologies/python) ([Markdown](https://aitinkerers.org/technologies/python.md)) — 662 public demos
- [RoBERTa](https://aitinkerers.org/technologies/roberta) ([Markdown](https://aitinkerers.org/technologies/roberta.md)) — 118 public demos
- [Server](https://aitinkerers.org/technologies/server) ([Markdown](https://aitinkerers.org/technologies/server.md)) — 6 public demos
- [Adobe XD](https://aitinkerers.org/technologies/adobe-xd) ([Markdown](https://aitinkerers.org/technologies/adobe-xd.md)) — 2 public demos
- [Anthropic](https://aitinkerers.org/technologies/anthropic) ([Markdown](https://aitinkerers.org/technologies/anthropic.md)) — 36 public demos
- [Anthropic API](https://aitinkerers.org/technologies/anthropic-api) ([Markdown](https://aitinkerers.org/technologies/anthropic-api.md)) — 66 public demos
- [APIs](https://aitinkerers.org/technologies/apis) ([Markdown](https://aitinkerers.org/technologies/apis.md)) — 19 public demos
- [Astro](https://aitinkerers.org/technologies/astro) ([Markdown](https://aitinkerers.org/technologies/astro.md)) — 3 public demos