Selected evidence

Claims should be visible, bounded and reviewable.

I separate work delivery from personal engineering and state what each example proves—without stretching it into a larger claim.

Four kinds of proof

Built, transferred, and operated.

Each example demonstrates a different capability. Their boundaries are part of the evidence.

Work · Active use 01

AI test automation

QA writes the intended workflow in natural-language test files. An Azure OpenAI worker executes bounded browser steps through Playwright MCP, collects evidence, and returns a result that can be reviewed.

Read the case summary ↓

Regression scope 10% → 80% Approximate operational change

Proves measurable adoption and practical AI delivery Does not claim AI removed QA or guaranteed defect reduction

Work · Handoff 02

Agentic IT support PoC

Built a bot-first support journey, then coached the delivery team on prompts, tools, escalation and productionisation.

What this proves: I can shape a use case, prove the path, and transfer it instead of keeping the knowledge with one builder.

Personal · Engineering lab 03

Multi-agent platform

A self-built environment—Next.js, TypeScript, PostgreSQL, Kubernetes—for understanding orchestration, MCP tools, multi-model routing through LiteLLM, approvals, policy, audit and operations as one system.

Honest boundary: serious personal engineering, not presented as enterprise traffic, revenue or staffed production scale.

Personal · Live on this site 04

First-party analytics platform

A self-built Stats API measuring this site right now: public beacon with bot filtering and rate limits, token-authenticated product metrics, a k-anonymity guard in Postgres, and Metabase dashboards—deployed by GitOps on my own cluster.

Verify it live: loading this page sent one anonymous pageview—no cookies, no stored IPs, and visitor hashes that cannot be linked across days.

Current case summary

More regression, without turning QA into programmers.

The value was not “AI writes tests.” The value was converting QA intent into repeatable work while preserving evidence and human responsibility.

01 · Problem

Manual capacity limited breadth

Development progress outpaced the amount of repeatable regression QA could cover.

02 · Change

QA writes intent in plain language

Azure OpenAI interprets the current step, acts in the browser through Playwright MCP and records what happened.

03 · Control

Evidence closes the step

Visible state, captured values and execution history support pass, retry or fail.

04 · Recovery

Failed steps self-heal with context

A failure is not blindly retried. The AI receives the previous failure, selector strategy hints, the attempted history and the current page state, then adapts its next action.

05 · Outcome

Wider regression and system testing

The repeatable regression scope expanded from about 10% to 80%, creating more room for system-level testing.

Illustration · the self-healing loop as an idea, not a work artifact

Intent

QA writes the step in a plain-language test file

Act

The agent performs the step in the browser

Check

Visible state and captured values decide the step

Pass

The step closes with evidence attached

On failure, the next attempt is not blind: the AI receives the previous failure, selector strategy hints, the attempted history and the current page state—then adapts.

What a test file looks like—an invented example of the format, not a work artifact.

# RT-04 · Checkout keeps the cart total

1. Open the shop and sign in as the demo user.
2. Add "Espresso Beans 500g" to the cart.
3. Open the cart. Expect exactly one line item.
4. Expect the cart total to equal the item price.

Test-automation dashboard with run totals, spend, token usage and cache hit ratio — **The tooling.** Run history at a glance—837 runs all-time, with spend, token usage and cache hit ratio tracked per suite and per run.

Test agent queueing a versioned suite of plain-language test files for an agent-driven browser run — **Queueing a run.** A versioned suite of plain-language test files heads to an isolated agent runner. Module codes and file names redacted.

Inside the personal platform

One system. Six layers. All self-built.

The multi-agent lab exists to understand the full stack of agent operations—not just prompts. Every layer below runs today on my own Kubernetes cluster.

01 · Interface

Chat and admin surfaces

Next.js and React in strict TypeScript, with multi-turn pending-state workflows and cross-session memory.

02 · Agent runtime

Stateless orchestration

DAG-based agents with per-node instructions, approval gates, skill routing and autonomous loops.

03 · Model routing

Multi-model by design

Claude, OpenAI, Gemini, Qwen and local Ollama models routed through a LiteLLM proxy with usage analytics.

04 · Tools

16 MCP services

Search, finance, analytics, sandboxed execution and more—each behind a validated tool boundary. Two are public: mcp-searxng and mcp-sandbox.

05 · Governance

Controls in code

RBAC, a scoped policy engine, audit trails, encrypted API keys and Vault-backed secrets.

06 · Operations

Run like production

Kubernetes with Kustomize overlays, sealed secrets, Gitea CI/CD and 139+ automated tests as quality gates.

Screenshots · Personal platform

Described above. Shown here.

Production screenshots from the personal platform, published after redaction review—identifiers and repository paths are masked.

Chat interface showing skill auto-routing and an MCP tool call with arguments and result — **Routing.** The request is matched to a skill from eighteen available, the model is selected and explained, and one MCP tool call runs—arguments, result and latency all visible.

Admin control plane listing skill agents with approval states and tool allowlists — **Governance.** The control plane: skill lifecycle with approval states, per-skill tool allowlists, and guardrail flags.

A mutating tool call held for human approval with its full arguments shown — **Approval gate.** The read-only tool ran freely; the mutating call stopped with its full arguments disclosed until a human approves. The prompt guides—code owns the hard stop.

Audit log of tool executions with success counts, errors and latency — **Audit.** Every tool execution is logged—1,169 successful calls with errors and latency in view. Conversation identifiers redacted.

Argo CD applications view with the full fleet of services synced from Git — **Operations.** The whole fleet—this site, the analytics stack, the MCP servers—declared in Git and reconciled by Argo CD. One tile mid-sync, because it is a live system.

The operating principle

Evidence before adjectives.

CV on LinkedIn ↗ Read my AI operating view → See how I would scale it →