Skip to main content
ZombieMutex

30 results · ↑ ↓ navigate · Enter open · Esc close

Personal notebook / Applied AI

Engineering projects

AI & ML Engineering

I have built the application and backend layers around AI agents, plus working audio-processing and machine-learning components. My focus is the point where model output becomes a tool action, a user-visible answer or a decision that needs to survive failure. The published case studies and source references document those boundaries.

Implementation areas

The parts that determine whether an AI system works

Architecture

LLM integrations & tool calls

I implemented typed tool contracts and first-party API gates that keep identity, tenant permissions and side effects outside the model’s authority.

Typed tool schemasPer-request identity and tenancyAllowlisted capabilitiesApproval for mutations

Implementation: Typed-tool execution models and backend integration

Evaluation

Model evaluation & reliability

I built repeatable evaluation fixtures and failure-path checks so changes to tool policies, prompts and integrations have concrete regression evidence.

Golden fixturesSafety and regression checksTimeout/error pathsCost and latency budgets

Implementation: Deterministic evaluations implemented

Model implementation

Applied machine learning

I implemented classification models and deterministic tests to isolate feature scaling, neighborhood choice, data coverage and distribution shifts.

Synthetic kNN classifierFeature scalingClass voting, not calibrationDataset limitations

Implementation: Working classifier implementation and controlled experiments

Native integration

Mobile & on-device inference

I separated native inference interfaces from backend policy, with hardware, latency, model versioning and offline behavior treated as explicit integration constraints.

iOS / Android integrationModel version and rollbackPrivacy boundariesDevice capability fallbacks

Implementation: Swift/Kotlin inference integration interfaces implemented

Execution architecture

Agent execution: where trust actually changes

Simplified trust-boundary view
  1. 01

    Untrusted input

    External data

    The user prompt, retrieved content or network response is not a source of privilege.

  2. 02

    Model / decision

    Probabilistic component

    Generated text and tool-call proposals are predictions, not authoritative instructions.

  3. 03

    Typed tool gateway

    Trusted policy enforcement

    The backend checks schema, identity, resource tenancy, capability scope and approvals before side effects.

  4. 04

    Execution & tracing

    Trusted service

    Execute only allowed operations, use bounded retries, record decision reasons without leaking secrets.

  5. 05

    Evaluation & rollback

    Operational feedback

    Replay regression fixtures, track failure modes and change model or prompt versions with a rollback path.

A system prompt is not the authorization boundary. The executor must validate permissions and resource ownership even when a model proposes a plausible action.

Voice agents / production integration patterns

The interface talks. The backend makes it safe.

I built the workflow gateway, signed CRM event handling, deterministic agent evaluations, reliability models and native iOS/Android callback integrations. The common thread is control over what happens after an agent proposes an action.

Voice agent engineering projects

SPEECH / MODELING / REAL-TIME INFERENCE

Audio ML implementations

I built and measured five local audio projects: speech-to-text evaluation, vector-quantized neural audio modeling, TTS prosody planning, streaming endpointing, and reproducible model training and ablations. They connect the model layer to the voice-agent systems I work on.

Explore the audio engineering

Inspectable engineering work

Published building blocks

I published the backend and security reference code that accompanies my systems work. The agent and audio-model projects have separate technical case studies; they use their own test results rather than borrowing credibility from unrelated demos.

Verified public source

Request idempotency under concurrency

I built and tested the request-fingerprint and idempotency code that controls repeated agent-triggered API writes.

Inspect public source
Verified public source

One-time challenge replay guard

I built a single-process challenge-consumption guard and exercised replay, mismatched identity and expiry cases.

Inspect public source
Published source and tests

Authorization and API failure analysis

I documented object-level authorization, retry and trust-boundary failures with deterministic test fixtures.

Explore evidence
Published engineering notes

Build log & engineering notes

Dated notes, reproducible tests and context for published code. Dated engineering changes, test results and source-linked implementation notes.

Explore evidence

Mobile and edge ML

What changes when inference moves to a device?

I developed Swift and Kotlin inference adapters that keep model execution separate from backend authorization. On-device inference also means handling CPU/GPU/Neural Engine variation, thermal throttling, model packaging, versioning, offline behavior and battery costs. The adapters are implemented; any accuracy or performance claim belongs to a specific trained model and device test.

iOS / Core ML

Measure cold-start latency, CPU/GPU/Neural Engine selection, memory pressure, model integrity and behavior when offline.

Apple Core ML docs

Android / LiteRT

Compare runtime acceleration and quantization tradeoffs, download/version verification, device compatibility and privacy costs.

Google LiteRT docs

Production review decisions

The production boundaries I use to review agent integrations:

  • Evaluate expected and adversarial behavior on versioned test fixtures.
  • Enforce tenant, resource and tool permissions outside model prompts.
  • Bound latency, concurrency, tokens, retries and spend.
  • Redact sensitive data in prompts, traces and analytics.
  • Version prompts, tools and models with rollback controls.
  • Measure failure cases, data drift and user-visible fallbacks.