Portfolio

Proof of client software, AI products, and agentic engineering.

Real project evidence for founders, operators, and contract leads evaluating FoxTech for workflow software, full-stack application development, AI-native products, compliance-aware rollouts, and practical agentic systems.

Decision guide

Use the case studies to decide what FoxTech can build with you.

Each project links the business problem to the delivered workflow, architecture, implementation stack, context-engineering approach, visual evidence, and contract relevance. The goal is to make it easier to judge whether FoxTech is the right partner for the kind of software, AI system, or engineering support you need.

Decision lens

Match the evidence to the risk in your project.

  • Client work shows delivery under real operating constraints.
  • In-house products show product thinking and full-stack web app build capability.
  • Agentic systems show practical AI infrastructure, retrieval, local models, and review loops.

Operations MVP

Turn operational mess into software.

Replace paper, inbox, spreadsheet, and role-handoff work with a usable operational web app.

Evidence: Spitfire Systems, CareSync

Sensitive rollout

Move sensitive products toward launch.

Build access controls, privacy operations, audit evidence, and launch support into the product.

Evidence: Mindful Message

AI-native systems

Make agentic workflows practical.

Embed AI into real workflows with retrieval, model tooling, review loops, and evidence capture.

Evidence: SocialFox, Context Engine, MLBot, local AI tooling

Client work

Client work that shipped under real constraints.

Client delivery where operational, compliance, or launch constraints had to become working software and reviewable rollout evidence.

Spitfire Systems service desk with populated work orders and status signals
Client workField-service operations MVP

Spitfire Systems field-service operations MVP

A fire-protection service workflow translated from paper and scanned work-order handling into role-based operational software.

Relevant when

For service businesses that need paper, inbox, technician, review, billing, and admin work turned into one traceable operational system.

View evidence

System architecture

How the system is put together

Spitfire Systems full field-service system architecture diagram

UML field-service architecture pipeline

Clean UML pipeline view showing role workflows, Next.js surfaces, application/domain logic, MVP stores, uploads, template mapping, and deployment seams.

Open architecture diagram
  1. 01Next.js routes and server actions compose the UI and submit workflow mutations.
  2. 02Application selectors and command handlers orchestrate session, form parsing, IDs, and revalidation.
  3. 03Domain modules own permissions, work-order pipeline decisions, audit filters, digital forms, and coverage rules.
  4. 04Infrastructure adapters handle JSON persistence and upload storage until a database/object-store layer replaces them.

Project definition

What problem this solves

Field-service work moved through fragmented service desk notes, technician activity, inspection forms, report review, billing handoff, and admin audit trails.

Work completed

What was built

  • Service desk, operations dashboard, technician queue, digital report review, billing handoff, and work-order lifecycle screens.
  • Domain/application/infrastructure layering so business rules do not live inside route components.
  • Digital inspection-template coverage with source-reference tracking and strict form audit evidence.
  • File-backed MVP persistence, upload handling, test isolation, Docker/standalone deployment notes, and handoff documentation.

Theory and context engineering

Techniques used in this project

These are the context-shaping decisions behind the work: how raw domain knowledge, system constraints, AI/tool boundaries, and evidence were turned into useful software behaviour.

01

Domain-context extraction

Paper forms, service desk notes, report-review steps, billing handoffs, and field activity were translated into explicit roles, states, and work-order transitions.

02

Source-grounded form modelling

Digital inspection questions were tied back to source-template references so workflow claims stay auditable rather than becoming undocumented form logic.

03

Role-context partitioning

Each surface presents the smallest useful context for the actor: service desk queue, technician field execution, report review, billing handoff, or admin audit.

04

Evidence-first MVP architecture

The file-backed store, uploads, audit records, tests, and Docker path preserve enough implementation evidence to review behaviour before committing to production infrastructure.

Skills and stack

Engineering capability shown

  • Workflow discovery
  • Domain modelling
  • Role-based UX
  • Digital form mapping
  • Audit trail design
  • Testing and deployment planning
  • Next.js 16
  • React 19
  • TypeScript
  • Server Actions
  • Vitest
  • Playwright
  • Docker path
  • File-backed JSON MVP store

Contract proof

What this proves about FoxTech delivery

Engineering surface

  • Workflow discovery
  • Domain modelling
  • Role-based UX
  • Digital form mapping

Stack evidence

  • Next.js 16
  • React 19
  • TypeScript
  • Server Actions
  • Vitest

Hiring relevance

For service businesses that need paper, inbox, technician, review, billing, and admin work turned into one traceable operational system.

User flow

How someone moves through it

  1. 1Service desk creates or reviews incoming work and assigns priority.
  2. 2Technician completes field activity and uploads inspection evidence.
  3. 3Reports move through digital review before billing and closure.
  4. 4Admin audit views preserve the operational trail and source-form coverage.

Usefulness

Why the work matters

  • Clarified handoffs across service desk, field technician, report review, billing, and admin roles.
  • Created a reviewable path from source inspection material to digital workflow behaviour.
  • The evidence package records 29 source templates, 1,229 digital questions, 1,260 source references, and no unmapped digital questions in the strict audit.

Screenshot evidence

Workflow and implementation evidence

Each image is tied to the project workflow so the gallery explains context, data state, and delivery relevance.

Operations dashboard

Shows the operational queues and role pipelines that make current work visible at a glance.

Service desk

Shows active work orders with assignment, status, risk signals, and review ownership.

Technician workflow

Shows the field worker view for assigned jobs, job status, receipts, payment, and photo upload readiness.

Report review

Shows how completed field work moves into review before customer reporting or billing handoff.

Work-order detail

Shows lifecycle state, next action, progress, role ownership, and audit-ready work-order detail.

Mindful Message privacy request workflow
Client workGDPR/HIPAA rollout support completed

Mindful Message GDPR/HIPAA implementation and rollout support

A mental-health referral and counselling SaaS brought through GDPR/HIPAA-oriented implementation, role-aware workflows, privacy operations, hosted evidence, and rollout support.

Relevant when

For founders operating in sensitive domains who need access control, privacy workflows, audit evidence, and launch support handled together.

View evidence

System architecture

How the system is put together

Mindful Message full sensitive-platform system architecture diagram

UML sensitive-platform architecture pipeline

Clean UML pipeline view showing role workflows, protected App Router surfaces, server-side policy controls, WorkOS, Cloud SQL, private storage, event streams, and rollout evidence.

Open architecture diagram
  1. 01Next.js App Router and server components compose protected dashboard families.
  2. 02WorkOS AuthKit, organization memberships, server-side permissions, and route guards define access rules.
  3. 03Server actions call data and compliance modules that own Prisma/PostgreSQL access, privacy workflows, audit trails, and evidence records.
  4. 04Authenticated SSE, private GCS, Resend, OpenTelemetry, backup/restore, and GCP monitoring support rollout evidence.

Project definition

What problem this solves

The founder needed the app made ready for GDPR and HIPAA operating expectations before rollout, across sensitive referral, counselling, assessment, privacy, billing, and reporting workflows.

Work completed

What was built

  • Implemented GDPR/HIPAA-oriented product controls across role access, privacy operations, audit evidence, data handling, and release readiness.
  • Built privacy request, compliance casework, audit schemas, retention, breach, DSAR, processor, and evidence-tracker surfaces.
  • Supported rollout and go-to-market with hosted baseline evidence across Cloud Run, Cloud SQL, private GCS, structured logging, backup/restore, scheduler, and monitoring.
  • Designed AI assistant capabilities around server-side permission checks, human review, and controlled sensitive-record workflows.

Theory and context engineering

Techniques used in this project

These are the context-shaping decisions behind the work: how raw domain knowledge, system constraints, AI/tool boundaries, and evidence were turned into useful software behaviour.

01

Regulatory-context modelling

GDPR, HIPAA-facing expectations, privacy rights, retention, breach, audit, and processor concerns were converted into product workflows and operational evidence.

02

Sensitive-context boundaries

Role access separates service-user, counsellor, organisation, admin, support, and AI assistant context so sensitive records do not leak into broad operational views.

03

Compliance casework as context loop

Privacy requests, DSAR exports, retention holds, breach records, and audit events preserve request state, actor context, due dates, and evidence paths.

04

Guarded AI tool design

Assistant capabilities are framed around server-side permission checks, reviewable tools, human confirmation, and explicit launch limits for clinical or ePHI context.

Skills and stack

Engineering capability shown

  • GDPR/HIPAA implementation
  • Sensitive-domain architecture
  • Role-scoped data access
  • Compliance engineering
  • Hosted evidence
  • Rollout and GTM support
  • AI governance
  • Next.js 16
  • React 19
  • TypeScript 6
  • WorkOS AuthKit
  • Prisma 7
  • PostgreSQL
  • Cloud Run
  • GCS
  • OpenTelemetry
  • OpenAI Agents SDK

Contract proof

What this proves about FoxTech delivery

Engineering surface

  • GDPR/HIPAA implementation
  • Sensitive-domain architecture
  • Role-scoped data access
  • Compliance engineering

Stack evidence

  • Next.js 16
  • React 19
  • TypeScript 6
  • WorkOS AuthKit
  • Prisma 7

Hiring relevance

For founders operating in sensitive domains who need access control, privacy workflows, audit evidence, and launch support handled together.

User flow

How someone moves through it

  1. 1Partner organisation and admin workflows manage referrals, sessions, billing, and operational metadata.
  2. 2Assigned counsellors retain access to sensitive clinical context while wider reporting stays redacted by default.
  3. 3Privacy requests, DSAR work, retention, breach, processor, and compliance workflows are handled as auditable casework.
  4. 4Rollout evidence supports launch decisions, stakeholder confidence, and go-to-market activity.

Usefulness

Why the work matters

  • Completed the implementation work the founder needed for GDPR/HIPAA-oriented operation and rollout.
  • Assisted the founder through full rollout and go-to-market rather than stopping at code changes.
  • Created a governed path for sensitive-domain AI by keeping tools server-side, permission-checked, and human-reviewed.

Screenshot evidence

Workflow and implementation evidence

Each image is tied to the project workflow so the gallery explains context, data state, and delivery relevance.

Privacy request workflow

Shows the privacy route used to explain data-rights intake, manual review, and controlled response handling.

Privacy request form

Shows the public intake form for access, export, deletion, correction, disclosure-accounting, restriction, confidential-communications, objection, and complaint requests.

Privacy request receipt

Shows the request receipt path where a submitted privacy case returns a reference and routes into manual compliance casework.

Privacy notice and data roles

Shows the public privacy notice explaining platform purpose, default role access, support-operator boundaries, and AI assistant limits.

Role access boundaries

Shows how counsellor, organisation, administrator, support-operator, and AI assistant access boundaries are made explicit for sensitive counselling data.

Lawful basis mapping

Shows GDPR lawful-basis and special-category-condition mapping across counselling, authentication, billing, compliance, emails, and telemetry purposes.

Retention and rights

Shows retention expectations, individual rights routes, cookie/performance-data limits, complaints guidance, and HIPAA-facing notice language.

HIPAA-facing notice

Shows the US HIPAA-facing notice language and boundary that separates platform notice wording from customer contract or BAA requirements.

Secure WorkOS access

Shows the authentication entry point explaining WorkOS-hosted sign-in, MFA/password-reset support, and the requirement for active role assignment before app access.

In-house product

In-house products aimed at market gaps.

Product systems aimed at market gaps, built to demonstrate full-stack web app capability from workflow model to usable interface.

SocialFox dashboard with populated social operations data
In-house productAI product with provider workflow evidence

SocialFox AI social operations command centre

An AI-native social media command centre for content operations, unified inbox triage, audience intelligence, analytics, and provider connections.

Relevant when

For product teams that want AI embedded into real operator workflows, with provider integrations, analytics, inbox triage, and review before action.

View evidence

System architecture

How the system is put together

SocialFox full AI social operations system architecture diagram

UML AI social operations architecture pipeline

Clean UML pipeline view showing operator workflows, command-centre surfaces, typed API contracts, FastAPI services, provider registry, data stores, AI context packs, and social integrations.

Open architecture diagram
  1. 01Next.js frontend uses a generated typed API package to call a FastAPI backend.
  2. 02Backend domains separate auth, content, analytics, messaging, social providers, gamification, AI, and settings.
  3. 03Provider registry and factory isolate YouTube, Instagram, Facebook, X, TikTok, WhatsApp, Telegram, Discord, and future platform capabilities.
  4. 04AI workflows are designed around analysis, draft generation, human approval, and platform execution.

Project definition

What problem this solves

Creators, agencies, and social operators manage posts, comments, reporting, audience signals, and channel connections across too many disconnected tools.

Work completed

What was built

  • Dashboard, content studio, unified inbox, analytics, audience intelligence, connections, settings, and AI assistant surfaces.
  • Provider-oriented backend architecture for social APIs, sync workflows, analytics, messaging, content, auth, and AI services.
  • Typed API package, frontend hooks, shared UI packages, observability, provider specs, testing standards, and local Docker workflows.

Theory and context engineering

Techniques used in this project

These are the context-shaping decisions behind the work: how raw domain knowledge, system constraints, AI/tool boundaries, and evidence were turned into useful software behaviour.

01

Provider-context abstraction

Platform-specific OAuth, account identity, capabilities, metrics, messages, and limits are normalized behind typed provider boundaries.

02

Operator-context composition

Dashboard, inbox, content, audience, and analytics views combine platform signals into the context a social operator needs at the point of action.

03

Human-in-the-loop AI workflow

Assistant and content-generation concepts are framed as draft, analyse, review, and approve loops rather than automatic publishing.

04

Signal-to-action modelling

Engagement, audience, content, and conversation signals are structured so they can drive triage, content planning, and reporting decisions.

Skills and stack

Engineering capability shown

  • AI product design
  • Provider integration architecture
  • OAuth workflow design
  • Analytics modelling
  • Multi-domain backend structure
  • Browser QA
  • Bun monorepo
  • Next.js
  • React
  • FastAPI
  • PostgreSQL
  • SQLModel
  • Clerk/OAuth
  • Typed API package
  • SSE AI chat
  • Docker

Contract proof

What this proves about FoxTech delivery

Engineering surface

  • AI product design
  • Provider integration architecture
  • OAuth workflow design
  • Analytics modelling

Stack evidence

  • Bun monorepo
  • Next.js
  • React
  • FastAPI
  • PostgreSQL

Hiring relevance

For product teams that want AI embedded into real operator workflows, with provider integrations, analytics, inbox triage, and review before action.

User flow

How someone moves through it

  1. 1Connect social accounts through provider-specific connection cards.
  2. 2Review performance and activity from the command dashboard.
  3. 3Plan or draft content in the content studio.
  4. 4Triage inbox conversations and audience segments.
  5. 5Use analytics to understand content, platform, and engagement trends.

Usefulness

Why the work matters

  • Shows an AI product where the assistant supports real operator workflows instead of sitting beside the product.
  • Consolidates dashboard, content, inbox, audience, analytics, and connection surfaces into one command centre.
  • Demonstrates integration and product architecture across multiple provider capabilities.

Screenshot evidence

Workflow and implementation evidence

Each image is tied to the project workflow so the gallery explains context, data state, and delivery relevance.

Dashboard

Shows audience, lifetime views, activity, top engagers, and channel context in one operating view.

Content studio

Shows multi-platform content cards and the workspace for planning or drafting social output.

Inbox

Shows the conversation triage surface where social comments and messages become reviewable work.

Audience intelligence

Shows CRM-style audience rows, engagement tiers, and segmentation concepts.

Analytics

Shows cross-platform performance panels intended to turn raw metrics into operating insight.

Connections

Shows provider connection cards and OAuth-oriented account management surfaces.

CareSync medication administration workflow
In-house productSeeded care-operations product system

CareSync care-home operations product system

A broad care-home management product prototype covering resident records, clinical workflows, operations, finance, kitchen, incidents, audit, physio, and patient portal surfaces.

Relevant when

For complex multi-role operations where the product value depends on covering the full workflow surface rather than a narrow demo screen.

View evidence

System architecture

How the system is put together

CareSync full care-home operations system architecture diagram

UML care operations architecture pipeline

Clean UML pipeline view showing care-home role workflows, App Router surfaces, route policy, domain services, clinical and operations stores, seeded review data, auth, and governance evidence.

Open architecture diagram
  1. 01Next.js App Router composes staff, admin, clinical, and patient route groups.
  2. 02Feature-owned services and actions move business logic out of routes.
  3. 03Drizzle and PostgreSQL provide the data layer, with domain schemas grouped around clinical, finance, operations, compliance, and auth concerns.
  4. 04Auth.js/NextAuth, route policy, assignment checks, and tenant/facility scoping shape role access.

Project definition

What problem this solves

Care operations span many roles and handoffs: admin, nurses, doctors, kitchen teams, managers, residents, finance, compliance, and operational staff.

Work completed

What was built

  • Resident directory, resident record, medication rounds, doctor dashboard, kitchen queue, patient portal, finance, inventory, incidents, audit, and physio surfaces.
  • Modular-monolith direction with explicit domains for identity, facility, clinical, nursing, doctor, patient portal, kitchen, finance, operations, schedule, compliance, and physio.
  • Docker review lane with seeded data, demo-mode guards, smoke verification, database migrations, and role-specific demo accounts.

Theory and context engineering

Techniques used in this project

These are the context-shaping decisions behind the work: how raw domain knowledge, system constraints, AI/tool boundaries, and evidence were turned into useful software behaviour.

01

Role-scoped care context

Resident, medication, doctor, nurse, kitchen, finance, audit, and portal surfaces expose different slices of the same operational domain.

02

Clinical-to-operational handoff modelling

Care records, meal requests, incidents, inventory, finance, vitals, and medication states are modelled as handoffs between roles rather than isolated screens.

03

Seeded review estate

Demo accounts, residents, queues, medication states, doctor alerts, kitchen tasks, and audit records make the system reviewable without production data.

04

Governance-aware UX

Audit, incidents, role policy, assignment checks, and facility scoping keep compliance context visible inside the operating workflow.

Skills and stack

Engineering capability shown

  • Multi-role product modelling
  • Regulated-domain UX
  • Domain modelling
  • Seeded demo systems
  • Permission-aware screens
  • Operational workflow design
  • Next.js App Router
  • React
  • TypeScript
  • Auth.js / NextAuth v5
  • Drizzle ORM
  • PostgreSQL
  • Tailwind
  • Docker review app
  • Playwright smoke checks

Contract proof

What this proves about FoxTech delivery

Engineering surface

  • Multi-role product modelling
  • Regulated-domain UX
  • Domain modelling
  • Seeded demo systems

Stack evidence

  • Next.js App Router
  • React
  • TypeScript
  • Auth.js / NextAuth v5
  • Drizzle ORM

Hiring relevance

For complex multi-role operations where the product value depends on covering the full workflow surface rather than a narrow demo screen.

User flow

How someone moves through it

  1. 1Admin manages residents, audit logs, facilities, users, and operational status.
  2. 2Nurses run medication rounds, vitals queues, care logs, and assigned resident work.
  3. 3Doctors review assigned residents, medication context, and critical alerts.
  4. 4Kitchen and operations teams handle food requests, diet settings, stock, incidents, and governance evidence.

Usefulness

Why the work matters

  • Demonstrates product-system thinking across clinical, operational, governance, resident-facing, and finance surfaces.
  • Shows how a complex domain can be decomposed into role workflows and reviewable seeded evidence.

Screenshot evidence

Workflow and implementation evidence

Each image is tied to the project workflow so the gallery explains context, data state, and delivery relevance.

Admin patients

Shows the resident directory and admin entry point for managing people and care records.

Patient record

Shows the detailed resident record with clinical context and record lifecycle actions.

Medication rounds

Shows nurse-facing eMAR work, due/administered/refused states, resident assignments, and closure queue concepts.

Doctor dashboard

Shows assigned patients, critical alerts, schedule context, and recent clinical activity.

Kitchen queue

Shows nutrition and meal-service workflow as an operational handoff from care records to kitchen work.

Audit trail

Shows governance evidence for changes, actors, entities, actions, and timestamps.

Agentic systems and AI tooling

Agentic systems and local AI tooling.

Research and local AI systems for agentic engineering: retrieval, model workflows, micro-agents, local generation, 3D assets, and evidence capture.

Context Engine dashboard
Agentic systems and AI toolingAgent infrastructure with retrieval evidence

Context Engine local GraphRAG and MCP infrastructure

A local GraphRAG and MCP-style context platform for improving coding-agent retrieval, dependency understanding, and reviewable agent work.

Relevant when

For teams exploring agentic engineering who need better retrieval, source-grounded context, dependency awareness, and reviewable agent behaviour.

View evidence

System architecture

How the system is put together

Context Engine full GraphRAG and MCP system architecture diagram

UML GraphRAG and MCP architecture pipeline

Clean UML pipeline view showing developer and agent workflows, dashboard surfaces, MCP tools, retrieval core, LanceDB, Memgraph, Ollama embeddings, private workspaces, and Docker boundaries.

Open architecture diagram
  1. 01Python MCP gateway exposes tools for search, blast radius, file context, dependency graph, architecture overview, and engine stats.
  2. 02LanceDB stores vector and full-text retrieval data while Memgraph stores graph relationships.
  3. 03Ollama/local embedding support keeps the stack runnable on local infrastructure.
  4. 04Vite/React dashboard provides visual observability for retrieval and benchmark workflows.

Project definition

What problem this solves

Agentic development breaks down when context retrieval is shallow, untraceable, or detached from code structure and dependency relationships.

Work completed

What was built

  • Containerized GraphRAG engine with ingestion, parsing, chunking, embeddings, graph building, retrieval, reranking, and MCP tools.
  • Hybrid LanceDB vector/full-text search with Memgraph graph traversal and local embedding support.
  • Dashboard surfaces for engine health, retrieval, pipeline state, benchmarks, memory/config direction, and capability evidence.
  • Capability register, adversarial review, rebuild backlog, and agent-harness documentation for evaluating the system honestly.

Theory and context engineering

Techniques used in this project

These are the context-shaping decisions behind the work: how raw domain knowledge, system constraints, AI/tool boundaries, and evidence were turned into useful software behaviour.

01

Hybrid GraphRAG retrieval

Vector search, full-text retrieval, dependency graph traversal, reranking, fusion, and memory signals are combined so agents receive grounded context slices.

02

Code-structure context

Files, chunks, functions, classes, methods, imports, calls, and dependency edges are indexed to support blast-radius and architecture questions.

03

Retrieval observability

Stage-by-stage diagnostics, score distributions, retained candidates, benchmark matrices, and token-cost views expose why context was selected.

04

MCP agent interface

Search, file context, dependency graph, engine stats, and architecture tools turn retrieval into a callable agent capability rather than a passive dashboard.

Skills and stack

Engineering capability shown

  • Context engineering
  • RAG system design
  • Graph/vector retrieval
  • MCP tool design
  • Agent workflow evaluation
  • Local AI infrastructure
  • Python
  • MCP
  • GraphRAG
  • LanceDB
  • Memgraph
  • Ollama
  • Docker Compose
  • Vite
  • React
  • TypeScript

Contract proof

What this proves about FoxTech delivery

Engineering surface

  • Context engineering
  • RAG system design
  • Graph/vector retrieval
  • MCP tool design

Stack evidence

  • Python
  • MCP
  • GraphRAG
  • LanceDB
  • Memgraph

Hiring relevance

For teams exploring agentic engineering who need better retrieval, source-grounded context, dependency awareness, and reviewable agent behaviour.

User flow

How someone moves through it

  1. 1Index a target workspace and build vector, full-text, and graph context.
  2. 2Ask retrieval questions through MCP tools or dashboard surfaces.
  3. 3Use dependency and blast-radius views to understand implementation risk.
  4. 4Feed relevant, source-grounded slices into agent work and verification loops.

Usefulness

Why the work matters

  • Demonstrates the meta-layer behind agentic engineering: building tools that improve agent context quality.
  • Shows ability to reason about retrieval, evaluation, private-source handling, and reviewable engineering workflows.

Screenshot evidence

Workflow and implementation evidence

Each image is tied to the project workflow so the gallery explains context, data state, and delivery relevance.

Context dashboard

Shows service status, pipeline surfaces, index metrics, and retrieval-operation cards in one local dashboard.

Query results

Shows a natural-language code question resolved into ranked chunks, scores, file paths, and retrieval configuration.

Stage-by-stage retrieval

Shows the retrieval pipeline breaking a query into stages, score distributions, retained candidates, and ranked code chunks.

Graph explorer

Shows file, function, class, and method nodes with dependency and call relationships for blast-radius review.

Live service health

Shows the Docker-backed services, indexing phase, file and chunk progress, and operational status during a live run.

Memory observatory

Shows working-memory concepts, confidence distribution, access patterns, and retrieval-bias signals used to improve agent context.

Benchmark matrix

Shows benchmark runs and retrieval quality metrics across chunking, embedding, reranking, scoring, memory, and fusion configurations.

Token cost observatory

Shows local-versus-online token usage, estimated cost, and per-stage spend signals for practical agent-infrastructure operation.

MLBot model training workflow
Agentic systems and AI toolingReproducible AI and quant research evidence

MLBot and Quant Engine research tooling

Local AI/ML and quant research tools covering market data, model training, explainability, strategy backtests, run inspection, and paper-webhook workflows.

Relevant when

For research-heavy products where experiments, model output, backtests, generated artifacts, and comparison views need to stay reproducible.

View evidence

System architecture

How the system is put together

MLBot and Quant Engine full research tooling system architecture diagram

UML ML and quant research architecture pipeline

Clean UML pipeline view showing research workflows, MLBot and Quant interfaces, FastAPI and Streamlit services, feature and strategy pipelines, data stores, paper execution, and reproducibility evidence.

Open architecture diagram
  1. 01MLBot uses FastAPI, Docker Compose, PostgreSQL, Redis, Python ML/backtest modules, and a dashboard frontend.
  2. 02Quant Engine uses Streamlit UI, FastAPI paper webhook service, SQLite run metadata, JSON artifacts, and LEAN/QuantConnect direction.
  3. 03Research flows keep generated runs inspectable rather than presenting a black-box signal.

Project definition

What problem this solves

Trading research needs reproducible experiment flow: fetch data, engineer features, train or inspect models, run backtests, compare outcomes, and keep results reviewable.

Work completed

What was built

  • MLBot dashboard/API prototype for market data, preprocessing, technical analysis, risk, backtesting, model training, explainability, and paper execution concepts.
  • Quant Engine strategy lab for natural-language strategy ideas, rule matrices, LEAN/Pine-oriented generation, local backtests, run ledgers, and compare/blend views.
  • Dockerized local review flows with generated AAPL backtest/model evidence and persisted run artifacts.

Theory and context engineering

Techniques used in this project

These are the context-shaping decisions behind the work: how raw domain knowledge, system constraints, AI/tool boundaries, and evidence were turned into useful software behaviour.

01

Experiment-context ledger

Runs keep strategy settings, market context, metrics, charts, generated artifacts, and comparison state so results remain inspectable.

02

Feature and window modelling

Market data, technical indicators, preprocessing windows, labels, model inputs, and backtest assumptions are treated as explicit context objects.

03

Explainability surface design

Training curves, metrics, feature importance, prediction context, and strategy outputs make model behaviour reviewable instead of opaque.

04

Natural-language strategy framing

Strategy ideas are pushed toward explicit rules, validation, artifacts, and run comparison before any execution or paper-webhook boundary.

Skills and stack

Engineering capability shown

  • ML workflow design
  • Backtest UX
  • Explainability surfaces
  • Research tooling
  • Artifact persistence
  • Research workflow framing
  • Python
  • FastAPI
  • Streamlit
  • Docker Compose
  • PostgreSQL
  • Redis
  • PyTorch direction
  • VectorBT concepts
  • SQLite
  • LEAN/QuantConnect direction

Contract proof

What this proves about FoxTech delivery

Engineering surface

  • ML workflow design
  • Backtest UX
  • Explainability surfaces
  • Research tooling

Stack evidence

  • Python
  • FastAPI
  • Streamlit
  • Docker Compose
  • PostgreSQL

Hiring relevance

For research-heavy products where experiments, model output, backtests, generated artifacts, and comparison views need to stay reproducible.

User flow

How someone moves through it

  1. 1Load or generate market-data research context.
  2. 2Run a model-training or backtest workflow.
  3. 3Inspect model metrics, loss curves, feature importance, and strategy outputs.
  4. 4Compare runs and keep artifacts available for review.

Usefulness

Why the work matters

  • Shows complex-domain software engineering beyond CRUD: research loops, modelling, explainability, and reproducible artifacts.
  • Demonstrates local AI and quant experimentation through reproducible runs, comparison views, and inspectable artifacts.

Screenshot evidence

Workflow and implementation evidence

Each image is tied to the project workflow so the gallery explains context, data state, and delivery relevance.

ML dashboard

Shows portfolio-style metrics, chart context, model status, and a local operational dashboard for research workflows.

Model training

Shows training configuration, run output, and learning curves from a populated local model workflow.

Analysis

Shows market-structure analysis and candidate charting used to inspect generated research context.

Explainability

Shows feature importance and prediction context so model behaviour is inspectable.

Strategy backtest

Shows strategy configuration, run controls, generated output, and AI-assisted strategy surface.

Quant run ledger

Shows persisted research runs and artifact selection for reproducibility and comparison.

Backtest artifact

Shows a generated backtest artifact and chart output from the local strategy workflow.

Compare and blend

Shows side-by-side strategy comparison and equity curve review rather than a single unverified score.

Water-spraying turret GLB viewer with particle stream
Agentic systems and AI toolingLocal AI tooling and 3D workflow evidence

Local AI tooling, RAG, TTS, and 3D asset generation

Local AI tooling for model serving, TTS, RAG experiments, micro-subagents, 3D asset generation, animation, physics-style scene tests, and browser validation.

Relevant when

For teams that need private local AI workflows, model tooling, retrieval experiments, asset generation, and browser validation on a workstation.

View evidence

System architecture

How the system is put together

Local AI tooling full workstation AI system architecture diagram

UML local AI tooling architecture pipeline

Clean UML pipeline view showing local operators, micro-subagents, workstation interfaces, local model runtime, RAG and asset pipelines, private stores, Blender, Three.js, and publication boundaries.

Open architecture diagram
  1. 01PowerShell launch scripts orchestrate local model, TTS, RAG, and media tooling on Windows.
  2. 02Local model runtimes, ComfyUI, and asset generators support private/local generation workflows.
  3. 03Micro-subagents handle bounded research, asset, retrieval, and verification tasks with explicit handoff notes.
  4. 04Blender exports GLB assets that are validated and displayed through Three.js/browser viewers.

Project definition

What problem this solves

AI-native delivery increasingly needs private local tools that can generate assets, run local model tasks, support retrieval, coordinate small agents, and validate outputs on the workstation.

Work completed

What was built

  • Local AI scripts for llama.cpp server launch, ComfyUI workflows, SDXL image generation, Wan media workflow direction, and Qwen TTS generation.
  • Local RAG and micro-subagent experiments for bounded task execution, retrieval support, and verification-oriented agent work.
  • Blender/GLB/Three.js pipeline for generated 3D scenes, including a water-spraying turret used to exercise modelling, animation, and particle/physics behaviour in one scene.
  • Browser viewers and screenshot evidence for GLB inspection, interaction checks, and asset review.

Theory and context engineering

Techniques used in this project

These are the context-shaping decisions behind the work: how raw domain knowledge, system constraints, AI/tool boundaries, and evidence were turned into useful software behaviour.

01

Local/private context control

Model serving, RAG, TTS, and asset-generation work are kept on the workstation when privacy, cost, or iteration speed makes local execution useful.

02

Micro-subagent decomposition

Research, generation, review, and verification tasks are split into bounded agent loops with explicit handoff evidence.

03

Multimodal context pipeline

Text prompts, model outputs, generated images, 3D geometry, animation, GLB exports, browser renders, and screenshots become one reviewable workflow.

04

Visual verification loop

The generated turret scene is inspected in browser viewers to check nonblank render, framing, animation controls, particle-style spray, and physics-oriented behaviour.

Skills and stack

Engineering capability shown

  • Local AI infrastructure
  • Local RAG tooling
  • Micro-agent orchestration
  • Multimodal workflow setup
  • 3D asset production
  • Animation and physics prototyping
  • Asset-governance discipline
  • llama.cpp
  • GGUF models
  • ComfyUI
  • CUDA
  • Qwen TTS
  • Local RAG
  • Micro-subagents
  • Blender
  • GLB/glTF
  • Three.js
  • PowerShell automation

Contract proof

What this proves about FoxTech delivery

Engineering surface

  • Local AI infrastructure
  • Local RAG tooling
  • Micro-agent orchestration
  • Multimodal workflow setup

Stack evidence

  • llama.cpp
  • GGUF models
  • ComfyUI
  • CUDA
  • Qwen TTS

Hiring relevance

For teams that need private local AI workflows, model tooling, retrieval experiments, asset generation, and browser validation on a workstation.

User flow

How someone moves through it

  1. 1Run local model, TTS, retrieval, or asset-generation tasks for a bounded objective.
  2. 2Use micro-subagents or scripts to isolate generation, review, and verification work.
  3. 3Export and validate generated 3D assets or media outputs.
  4. 4Inspect the result in a browser viewer and keep screenshot evidence.

Usefulness

Why the work matters

  • Shows hands-on AI infrastructure beyond hosted API calls, including local model use, TTS, retrieval, and small-agent workflows.
  • Demonstrates how generated 3D assets can be validated in-browser, with the turret scene combining geometry, animation, and particle/physics behaviour in one test surface.

Screenshot evidence

Workflow and implementation evidence

Each image is tied to the project workflow so the gallery explains context, data state, and delivery relevance.

Water-spraying turret scene

Shows a generated GLB scene used to test modelling, animation controls, particle-style spray, and physics-oriented behaviour in one browser viewer.

Work with FoxTech

Bring a product, workflow, compliance constraint, or AI engineering problem.

The strongest fit is a project where the business process, software architecture, data boundary, or AI workflow needs to move from unclear risk to working, reviewable software.

Discuss a projectSee services

FoxTech Consulting

Full-stack software engineering, bespoke applications, AI adoption, context engineering, agentic workflows, and operational automation.

Foxtech Ltd

consulting@foxtech.app

Production domain: foxtech.app