Design the workflow
Explicit tasks, structured tool contracts, persisted state and deterministic gates around model decisions.
AI engineering
Building AI systems that can act — and be checked.
My focus is applied AI engineering: agent orchestration, LLM-powered tools and the infrastructure that makes their behaviour observable, recoverable and bounded by explicit authority.
Approach
More than prompting a model
Prove the boundaries
Least privilege, isolated execution, independent review and honest documentation of failure modes.
Measure the outcome
Tests and repeatable evaluations, not demo videos or model-generated claims of success.
Selected systems
What my work demonstrates
Three systems I built, each with public code and a detailed case study.
Agent orchestration & reliability
Acthelm
An agent-driven operating system with persisted task state, deterministic triggers, isolated code changes, independent model review and explicit release authorisation.
Engineering evidence
- Agent lifecycle and task orchestration
- Tool execution boundaries and human approval
- Crash recovery and auditability
Scope: Active development; do not treat its Stage C design as proof of fully unattended execution.
LLM applications & agent-facing tools
Seerxo
A live product with CLI, local and remote MCP integrations, an API and a rule-based listing audit kept separate from generative operations.
Engineering evidence
- MCP and tool schema design
- LLM-backed product integration
- Deterministic validation and API contracts
Scope: The backend is not public; the case study is limited to verified client code and documented interfaces.
Supporting work · SSH security engineering
SigSieve
Not an AI project: a Rust SSH-agent proxy that limits which keys can be forwarded and can bind them to trusted destination host keys. It shows the security habits I apply to AI infrastructure.
Engineering evidence
- Threat modelling and least privilege
- Protocol-level security controls
- Test-driven handling of failure modes
Scope: Experimental security software. Not independently audited; no claims of complete protection.
For code reviewers
Where to start in the code
Technical references, reviewed on 3 November 2026. Explore the implementation at pinned source revisions: Acthelm b8b7e77, Seerxo 8c52984 and SigSieve alpha.4 5ea37b7.
- Deterministic work detection — no work, no model call
app/business_reconciler.py - Golden evals: “done” without evidence is rejected
evals/test_supervisor_evals.py - Untrusted-content encoding and approval-escalation tests
evals/test_trust_evals.py - Crash-recovery tests against real PostgreSQL
tests/test_worker_crash_recovery_postgres.py - MCP tool schemas with explicit limitations
src/mcp/tools.js - End-to-end test of the stdio MCP server
tests/stdio-mcp.test.js - Threat model
docs/THREAT_MODEL.md - Findings register: every issue and its fix
docs/FINDINGS.md
AI evaluation & reliability
Validation built into the workflow
Deterministic tests cover structured output, unsupported completion claims, recovery and tool contracts. “In CI” identifies tests in the project’s test workflow. Model-level performance is a separate measurement; the table distinguishes implemented checks from dimensions without a reported benchmark.
| Dimension | Status | Evidence |
|---|---|---|
| Structured output validation | In CI | Malformed or off-task agent results are rejected · evals/test_supervisor_evals.py |
| Unsupported claims | In CI | “Done.” without evidence returns REVISION_REQUIRED · evals/test_supervisor_evals.py |
| Prompt injection | Partial | Encoding and escalation scenarios are tested; these do not establish real-model injection resistance · evals/test_trust_evals.py |
| Security boundaries | In CI | Trust-boundary tripwires for CI permissions and credentials · tests/test_trust_boundary.py |
| Agent recovery | In CI | Crash and stale-run recovery against real PostgreSQL · tests/test_worker_crash_recovery_postgres.py |
| Regression scenarios | In CI | Stage C golden scenarios, each naming the failure it catches · evals/test_stage_c_runner_evals.py |
| Tool contracts (MCP) | In CI | stdio MCP server tested end to end in Seerxo · tests/stdio-mcp.test.js |
| Task completion rate | Not reported | — |
| Model-level tool-call accuracy | Not reported | — |
| Latency per task | Not reported | — |
| Cost per task | Not reported | Policy only: metered API keys are refused · agents/cost_policy.yaml |
Evaluation roadmap
Evidence needed for model benchmarks
The deterministic tests above check control-plane behavior. A model benchmark would additionally need the following evidence; this is an evaluation method, not a committed product roadmap:
- A versioned task suite with fixed inputs and success criteria the supervisor can check
- Each run recorded with provider, model version, transcript, tool calls and outcome
- Metrics per suite version: success, partial success, false approvals, recoveries, latency and resource use
- A CI job that runs the deterministic part on every change and the model part on demand, publishing raw results
These are evaluation questions, not published benchmark results. A result needs defined tasks, methodology and raw evidence before it can support a claim.
Can an agent complete work reliably?
Create a versioned, repeatable task suite. Report task success, partial success and failures with the test conditions and sample size.
When does multi-agent review help?
Compare a single-agent baseline with coder-plus-reviewer workflows on the same tasks. Record reviewer disagreements and false approvals.
What happens when tools fail?
Inject timeouts, invalid tool output, stale state and interrupted runs. Measure recovery and identify where human intervention is required.
What is the cost of autonomy?
Measure latency, token/API usage where applicable, and resource costs per completed task; do not conflate subscriptions with per-token pricing.
Currently not claimed: a demonstrated RAG benchmark, custom-trained foundation model, independently audited agent security, or measured production-level autonomous task success. These require separate evidence.
Public work & community
Build in public, make the work useful
Reusable code, technical documentation and transparent limitations are part of the work. SigSieve and the Seerxo client have public source and MIT licences; Acthelm has public source but currently no open-source licence. The distinction matters.
SigSieveSecurity model, limits, installation and source →SeerxoMCP tools, CLI documentation and source →Technical researchArchitecture studies with evidence and limitations →
Security concerns should be reported via each repository’s security policy, not public issue threads.
Interested in working together?
I am pursuing AI Engineer, Applied AI Engineer and LLM / Agent Engineering roles. My strongest evidence is in agent systems, developer tools and backend infrastructure.