18 months of applied AI research

Researching how intelligent systems reason, use tools, understand context, interact with software, and move from prototypes into real products.

A public archive of experiments, systems, engineering decisions, observations, and research notes.

I started this research because using AI APIs was no longer enough. I wanted to understand what was actually happening beneath the interface: how models behave, where they fail, how AI systems should be architected, and how far they can be pushed inside real software.

Over the last 18 months I have worked through language models, agents, retrieval, tool use, computer vision, structured reasoning, context engineering, evaluation, and production AI architecture — including QuoteSnap AI, hands-on model experiments, and architecture studies of Cursor, Bolt, and Decide.

What I am trying to understand

1. How should modern AI systems be architected beyond calling an LLM API?
2. How much of an intelligent system’s apparent intelligence comes from the model versus the surrounding architecture?
3. What happens when models are given memory, tools, context, retrieval, and the ability to interact with external systems?
4. Where should probabilistic AI stop and deterministic software begin?
5. How should AI systems behave when information is incomplete or uncertain?
6. How do we evaluate AI systems whose outputs cannot always be judged with deterministic tests?
7. How can AI systems remain useful under cost, latency, connectivity, and infrastructure constraints?

Experiments

• Is conversation history a memory system? — Treating the full transcript as memory versus storing task state.
• Should the model compute, or should code compute? — Internal model arithmetic versus plan-then-execute on spreadsheet-like tasks.
• Can an LLM own the entire quoting workflow? — End-to-end generation versus interpretation plus deterministic pricing in QuoteSnap AI.
• Can downstream software consume unconstrained prose? — Natural-language job summaries versus validated structured signals before pricing.
• Can the context window stand in for the repository? — Observational study of coding agents on codebases larger than the window.
• Is semantic similarity enough to find the controlling code? — Authentication-style queries retrieve related UI and still miss middleware and policy.
• What changes if I stop treating the LLM as an API? — Hands-on model work: data, tokens, embeddings, attention, inference, and serving constraints.
• Does re-explaining the project every turn work? — Repeated briefing versus persistent rules, files, and task-scoped chats.
• Is code generation enough without a run loop? — Generate-once versus generate, run, inspect, and repair inside an environment.
• Do vague requests produce useful coding-agent behaviour? — Unspecified “vibe” prompts versus task-first requirements, conventions, and expected behaviour.
• Should a coding agent live in one endless chat? — Long sessions versus a new chat per task, with bugs written as tasks.
• Should the agent start from a blank repository? — Greenfield generation versus a TypeScript boilerplate that already encodes product decisions.

Systems

• QuoteSnap AI — Applied system: image-assisted estimating where AI interprets and software prices.
• Small language model experiments — A hands-on model stack used to understand tokens, training, inference, and serving — not a chatbot product.
• Task-first coding-agent system — Boilerplate, rules, specifications, and feedback loops used to ship production SaaS with coding agents.

Current questions

• How should long-running agents maintain useful memory without unbounded state?
• How should context-ranking systems combine semantic similarity with structural relationships?
• What is the right architecture for measuring confidence across multi-step agent workflows?
• How should autonomous systems decide when to stop and request human intervention?
• Can specialist small models combined with tools outperform much larger models for constrained workflows?
• How should agent permissions be represented when tools expose real business systems?
• How much agent behaviour should live in prompts compared with explicit software orchestration?
• How should AI products degrade when their primary model or external tool becomes unavailable?

Lab

• Context Packing — How much of a codebase does an agent actually need?
• Memory vs History — Is keeping the entire conversation the same thing as remembering?
• Where Should AI Stop? — A model can make the decision. Should it?
• Agent Execution Trace — What makes a coding agent look intelligent?

Research principles

• Document failures, not only the work that shipped.
• Separate observation from interpretation.
• Do not hide negative results.
• Make experiments reproducible where possible.
• Publish methodology and state limitations.
• Do not generalise beyond the evidence.
• Update conclusions when new evidence appears.
• Say when a finding comes from a product I studied rather than a system I built.

This archive contains independent research, experiments, architecture studies, and technical observations. Some findings are exploratory and should not be interpreted as peer-reviewed scientific conclusions unless explicitly stated. Architecture studies of third-party products are based on publicly observable behaviour, published technical information, and engineering analysis. They are not claims of access to private source code or infrastructure.