Making complex products
feel simple.

01 / What I built

A research question becomes a visible workflow.

FinanceHermes is an independent financial-research and education prototype. A user asks a question, the agent chooses tools, reads source material and streams its activity before returning a source-linked answer. The interface makes the research process inspectable instead of showing only a final block of text.

Research mode combines model reasoning with web search and page extraction. Learn mode narrows the available tools to a curated educational library. They share the same agent endpoint but have different tool permissions and run budgets.

02 / How the system works

A small stack, with the orchestration made explicit.

1. Browser → serverless endpointStatic HTML, CSS and JavaScript send the question to a Node.js function on Vercel. The project declares no npm dependencies; provider credentials stay server-side.
2. Model → tools → modelThe server calls an OpenAI-compatible model provider, reconstructs streamed tool-call arguments, runs approved tools and returns their results to the model. It supports structured calls and Hermes-style inline calls.
3. Streaming → final synthesisServer-Sent Events carry status, output and tool activity to the browser. Separate timeouts and step limits bound a run before final synthesis.

03 / Grounding and quality checks

Retrieval and citations are part of the implementation.

Research uses Tavily-backed search and extraction when configured. The local learning library uses keyword ranking with stemming, title weighting and phrase bonuses. A deterministic final pass checks educational links against the library and repairs plausible but nonexistent article paths.

An offline mock harness exercises the real agent loop against controlled upstream responses, including tool-call formats, streaming events, missing credentials, Learn restrictions, link repair and optional access-code gating.

This is a research and education demo, not financial advice. A linked source is not a guarantee of accuracy. Live research depends on configured services; educational content needs review and refresh. The access-code gate is not a subscription billing system.

04 / The interface

Start with the question.

01 / What I built

Find a local butcher, then understand the score.

The Six Cut is a Toronto-focused discovery product for independent butcher shops. It brings location, specialties, opening hours, shop details and ratings into a map-and-list experience, with an explainable score alongside the underlying information.

Users can search, filter and compare shops, then open a profile for the score breakdown, contact details and available imagery. The score is intended as a useful comparison signal, with its method exposed for readers to question.

02 / The build

Discovery, structured data, and a resilient interface.

1. Discover and cleanGoogle Places discovery scripts search overlapping areas across Toronto, deduplicate by place ID and filter named chains and non-operational businesses. Neighborhoods are assigned approximately from location.
2. Store and serveSupabase/Postgres holds published shop data. Server routes resolve Google photo references and reviews without exposing the service key to the browser.
3. Explore and compareNext.js, React and TypeScript power the product, with Mapbox for map browsing and filters for text, specialty, opening status and score. If the map cannot initialise, the interface falls back to a list.

03 / The scoring method

Weighted signals, with the ingredients visible.

The Six Cut Score uses deterministic review-text heuristics rather than an LLM making a subjective judgement. A lexicon finds positive and negative signals for quality, service and butcher craft, then combines them with the Google rating and review volume.

• 40% · QualityReview-text signals about meat quality.
• 20% · ServiceSignals about the customer experience.
• 15% · CraftMarkers of specialist butcher skills.
• 25% · Rating + volume15% normalised rating and 10% logarithmic review volume.

The implementation smooths positive/negative ratios, caps repeated matches and reduces the weight of text components when the review sample is small. Refresh runs combine currently returned reviews with previously observed signal counts in a recent window; the archive stores derived signals rather than raw review text.

Google supplies a limited review sample. Heuristics can miss context, language nuances and sarcasm, so the score is not a comprehensive quality judgement. Refresh tooling exists; a reliably scheduled refresh is not claimed here.

04 / The interface

Make the result explainable.

01 / Personal build

Knowledge that carries between conversations.

My personal knowledge base is a set of cross-linked markdown notes used as shared context by Claude Code and the other agents I work with. It gives me something persistent to revisit and connect, rather than leaving everything inside individual chats.

The building blocks are deliberately legible: notes, links and a knowledge format that can be inspected alongside the tools using it. The graph is a way to navigate those connections; the useful part is the information behind each node.

02 / The system pattern

Sources, connected knowledge, and rules for upkeep.

Karpathy’s LLM Wiki describes a useful pattern: keep source material, build an interlinked markdown wiki from it, and give the agent conventions for maintaining that wiki. Adding a source, answering a question and checking for stale or contradictory claims become explicit workflows.

Open Knowledge Format adds a way to describe context consistently. Its v0.2 trust signals can carry provenance, verification and freshness information, so a consumer can assess what it is about to use. Those fields describe trust; permissions still need to be enforced by the surrounding system.

03 / Proposed organisational extension

A shared asset that the business owns.

I think businesses should build organisationally owned and managed context systems for employees and their AI tools. Decisions, research, policies and ways of working should connect back to sources, with clear owners, review points and a traceable record of updates.

The ambition is continuity: a team should be able to reuse what the organisation has learned instead of rebuilding the same background for each new person or task. This is the broader product direction I see growing from the personal knowledge-system idea.

04 / Proposed client context

One relationship, with its history intact.

A permissioned context record for each client could bring together relevant communications, preferences, commitments and service history. Emails, messages and call summaries can support that view where their capture is appropriate and authorised.

Observed events and source-backed facts should remain separate from AI summaries and modelled estimates such as client lifetime value (CLV). Assumptions and freshness need to be visible. Ownership also means access controls, consent where required, purpose-limited capture, and retention and correction processes.