VENN :: PORTFOLIO CASE STUDY  — THE DIMENSIONAL FORGE
DF-VNN-001
Role Lead Engineer · Solo build
Timeline 2025 – Present · Active
Stack JavaScript · Node.js · HTML/CSS · SSE · LLM APIs
Type Production Tool · Daily use
VENN
AI assistant built for The Dimensional Forge

A browser-based AI assistant I designed and built from scratch to handle the administrative layer of running a solo engineering consultancy — scheduling, quoting, pricing, and notes — so I can stay focused on the actual engineering work.

The Problem
Why This Exists
The Problem
Context-switching is the real cost of running a one-person business

The Dimensional Forge is a one-person engineering consultancy. Running it means doing two jobs at once: the creative engineering work, and the administrative layer that makes the business function. Every hour spent on scheduling, pricing, and note-taking is an hour not spent solving engineering problems.

The friction points
  • Every client booking required jumping between email and Google Calendar manually, then confirming back and forth.
  • Quoting a 3D print job meant calculating material cost, print time, and setup fees from scratch — each time, for every job.
  • Meeting notes were taken by hand during calls, then typed up later — always incomplete by the time they were filed.
  • Off-the-shelf AI assistants store data in the cloud, can't reach local tools or files, and cost money per conversation at scale.
The goal
  • Build a single conversational interface that handles the ops layer — scheduling, quoting, note-taking, pricing — through voice or text.
  • Keep all data local. No third-party cloud. No subscription. No per-message cost beyond the AI model itself.
  • Make it modular so new capabilities can be added without rebuilding the core.
How It Works
Engineering Approach
How It Works
Single HTML file · modular bridge servers · any LLM backend · runs on a phone

VENN is a single HTML file that opens in any browser. It connects to an AI model — local or cloud — and gives that model access to capabilities through "bridges": small Node.js servers that each expose a standard two-endpoint API.

The key engineering decision: dynamic tool injection
  • The overhead problem: Most agent frameworks send descriptions of every available tool to the LLM with every message. A simple "what's on my calendar?" question triggers thousands of tokens of overhead — the model processes file tools, hardware tools, and estimators it doesn't need for that task.
  • What VENN does instead: The LLM first calls a lightweight list_bridges function to discover what's active. Only the schemas for currently-enabled bridges get injected. Disabled bridges cost zero tokens.
  • The result: 125–435 tokens per turn, vs. 2,000–20,000+ for standard frameworks — small enough to run on a local 1.7B model on an Android phone.
The bridge architecture
  • Each bridge is an independent Node.js server exposing two endpoints: GET /tools returns its tool schemas, POST /execute runs the tool. The LLM never calls a bridge directly — all routing goes through Master Control.
  • New capabilities (calendar integration, Flipper Zero, print estimator, voice synthesis) are added as new bridges. The core system doesn't change.
  • A memory bridge with a hard 280-token ceiling keeps context lean across sessions: a user profile always in context, plus keyword-retrieved notes from past sessions.
Live example below: "Can you help me with a 3D printing quote?" — VENN checks the file folder for the STL, runs the print estimator to calculate weight, time, and cost, then opens the estimate in the browser. Four tool calls. One natural conversation. No manual steps.
● IDLE
INPUT ▶ LLM ▶ TOOL ▶ RESPONSE
—
◈ VENN ◈
USER15:55 VENNQWEN3-1.7B · llama.cpp MASTER:7852 · router IDE Bridge:7853 · file tools Print Estimator Bridge:7867 · 6 tools list_dir estimate_print list_estimates open_estimate OUTPUTlight-bar-floor-bracket-v2-1.html · 27.1 g · 44 min · $14.64 BROWSERsystem default REQUEST RESPONSE
step 1 / 10
// STEP 1 — BRIDGE STARTUP · 15:55:04
[master]Control Bridge running on :7852
[bridge-toggle]User enabled: printEstimator · checking now: true
[print-estimator]Bridge started on :7867 · 6 tools ready
// STEP 2 — TURN 1 · USER → LLM → RESPONSE
▶"Hi Venn - Can you help me with a 3d printing quote?"
[llm]no tool call — asking user to confirm file location
// STEP 3 — TURN 2 · list_dir → IDE :7853
▶"Yes it's there - the Floor Light Bracket"
{
  "name": "list_dir",
  "args": { "path": "brain/inputs/print-estimator/" }
}
[master]routing list_dir → IDE Bridge :7853
// STEP 4 — list_dir RESULT
[ide]→ Light Bar Floor Bracket V2.1.stl (491 kB, May 28)
[llm]file confirmed — asking: material? profile? quantity?
// STEP 5 — TURN 3 · estimate_print → PRINT EST :7867
▶"Just one, lets run defaults PLA, and standard"
{
  "name": "estimate_print",
  "args": { "stl_path": "Light Bar Floor Bracket V2.1.stl", "material": "PLA", "quantity": 1 }
}
// STEP 6 — estimate_print RESULT · 27.1g · 44 min · $14.64
Profile: 0.20mm Standard · Material: PLA × 1
Weight: 27.1 g · Time: 44 min · Total: $14.64
// STEP 7 — TURN 4 · list_estimates → PRINT EST :7867
▶"Please do"
[llm]decision: list_estimates({}) → confirm filename before opening
// STEP 8 — list_estimates RESULT
[print-estimator]→ light-bar-floor-bracket-v2-1.html (May 28)
[llm]decision: most recent match → call open_estimate next
// STEP 9 — open_estimate → BROWSER
[print-estimator]open_estimate → opened in default browser
// STEP 10 — SESSION COMPLETE
◀"Done! The estimate is open in your browser now."
In Practice
Results
In Practice
6 capability areas now handled by VENN · Calendar · Quoting · Pricing · Notes · Knowledge · Automation
◆ Scheduling
Calendar & Appointments
Books client meetings, follow-ups, and project milestones via natural language. Google Calendar bridge — no manual entry, no back-and-forth email chains.
Email chains → one message to VENN
◆ Quoting
Project Quotes & Estimates
Pulls from Obsidian's knowledge base — actual previous deliverable timelines, real material costs, past project notes. Estimates grounded in what TDF has actually shipped, not guesses.
Research + calc → minutes, not an hour
◆ Pricing
3D Print Job Pricing
Input part dimensions and material, get a cost estimate instantly. Material pricing, volume estimates, setup fees — pulled from stored pricing data in the knowledge vault, not recalculated each time.
Lookup + math → seconds
◆ Memory
Notes & Knowledge Capture
Takes meeting notes directly into Obsidian. Appends to project files, tags entries, creates daily notes. Structured capture without breaking focus — nothing falls through the cracks between client calls.
Manual note-taking → spoken + captured
◆ Learning
Growing Technical Memory
Reviews the knowledge folder to learn how technical challenges have been solved before. Surfaces relevant past solutions when new work resembles old problems.
Re-learning each time → persistent context
◆ Automation
Repetitive Task Automation
Research synthesis, file organization, supplier lookups, draft responses — routed through VENN so they run fast and consistently. The constraint is always the creative work, never the admin.
Bottleneck removed → creatives stay in flow
Honest evaluation VENN works well for the tasks it was designed for. The scheduling and pricing flows are reliable daily drivers. The weakest area is the knowledge retrieval — BM25 search works but returns noisy results when the knowledge base gets large, and I haven't yet built a proper re-ranking layer. Voice input via SAM is functional but the retro 8-bit synthesis is genuinely difficult to understand at speed; Piper is better but requires more setup. The architecture is sound, but the UX still requires knowing what to ask and how to phrase it — it's not yet a product someone else could pick up without onboarding.
Architecture
System Design
Architecture
Single-file PWA · 18 modules · dynamic LLM orchestrator · runs on anything from a phone to a Raspberry Pi

VENN is a single HTML file. It connects to an AI model — local (Ollama, llama.cpp) or cloud (Claude, OpenRouter) — through a standard OpenAI-compatible API. Each "bridge" is a small Node.js server that gives the AI access to a new capability. You plug in only what you need. All routing goes through Master Control; the AI never calls a bridge directly. New bridges can be added without touching the core system.

LOCAL · OFFLINE CLOUD OLLAMA REST API · OAI-COMPAT LLAMA.CPP SERVER · HTTP · NATIVE LM STUDIO GUI · API · MODEL MGMT OPENROUTER MULTI-MODEL · PROXY CLAUDE API ANTHROPIC · CLAUDE 4.x OPENAI COMPAT GPT FORMAT · STANDARD VENN.HTML MULTI-TOOL · CLOUD REACH · HARDWARE I/O · ZERO INSTALL HOT-SWAP LLM EXPANDABLE BRIDGES PHONE · PC · PI ZERO INSTALL MEM OVERHEAD 280 TOK MAX 125–435 / TURN MASTER CONTROL :7852 BRIDGE REGISTRY · ORCHESTRATION · IDE / SHELL EDGE HARDWARE IDE BRIDGE :7853 · R/W/LIST/RUN · 4 TOOLS ESP32 :7854 · UART 115200 · GPIO ANDROID :7855 · TERMUX · SHIZUKU FLIPPER ZERO :7860 · USB-CDC · 22 TOOLS THE AGENTIC CORE MEMORY :7858 · 280 TOK CEILING KNOWLEDGE :7861 · BM25 + RAG · 4 TOOLS OBSIDIAN :7863 · VAULT · 11 TOOLS REFLECTION :7864 · IDENTITY · APPROVAL HEART :7870 · PULSE · SCHEDULER PRESENCE · OBSERVABILITY VOICE SAM :7856 · SAM 1982 · RETRO TTS VOICE PIPER :7857 · LOCAL · HI-QUAL SECURITY :7859 · FACE-API · ON-DEVICE TELEGRAM :7862 · BOT · FILE ROUTING PROJECTION :7869 · MIRACAST / CAST BUSINESS OPS GOOGLE :7865 · OAUTH2 · CAL+GMAIL TIMELINE :7866 · GANTT · HTML PRINT EST. :7867 · STL · 6 TOOLS
Back to Top