SKILLFUL ALHAZEN Technical Architecture Walkthrough

</> A WALKTHROUGH

# Skillful
Alhazen

Designing an ontology-backed notebook for agentic curation -- decisions, tradeoffs, and what I learned.

Brief

"The duty of the man who investigates the writings of scientists, if learning the truth is his goal, is to make himself an enemy of all that he reads, and, applying his mind to the core and margins of its content, attack it from every side."

-- Ibn al-Haytham, 965-1039 AD

Speaker Gully Burns
Role Principal AI Architect
Date May 2026
02.THE PROBLEM What I set out to solve

The starting point

## The agent was smart.
Its memory was post-it notes.

We anthropomorphize "memory" in agent work. But scientists don't remember everything -- they use notebooks. They write things down with structure so they can find it later and subject it to scrutiny.

Bioinformatics taught us data hygiene 20 years ago. We built ontologies for exactly this reason. The same problem is back.

[ IMAGE PLACEHOLDER ]
Conceptual diagram: post-it notes scattered on a wall vs. a structured lab notebook with typed entries
03.THE REALIZATION You're building a platform whether you know it or not

Solomon Hynes -- AI Engineering World's Fair, 2025

04.THE DEEPER ISSUE Implicit ontological commitments

The intellectual motivation

## Every agent makes ontological commitments.
Most are invisible.

LLMs are so good at semantics that we stop noticing the modeling decisions buried in prompts and markdown.

What's a "contact"? What's a "finding"? What's the relationship between a person and a role?

This framework makes those commitments explicit and evolvable.

[ IMAGE PLACEHOLDER ]
Conceptual diagram: implicit commitments (buried in conversation threads and MD files) vs. explicit commitments (typed schema with clear entity/relation definitions)
05.DECISION 1 Use a knowledge graph, not files

Decision one

## Structured memory,
not Markdown sprawl.

What most agent stacks do

Save context to MD files or a RAG index. Fine for chat. Falls apart when you need to ask structured questions.

What I chose

TypeDB: typed entities, typed relations, persistent across sessions, queryable across domains. Harder to set up. Worth it.

[ IMAGE PLACEHOLDER ]
Diagram: flat files and RAG blobs on the left; a knowledge graph with typed nodes and labeled edges on the right
06.DECISION 2 Skills as the unit of extension

Decision two

## Domain becomes a plug-in,
not a rewrite.

Anatomy of a skill

    skills/jobhunt/
      SKILL.md            // agent instructions
      schema.tql          // typed schema namespace
      jobhunt.py          // CLI commands
      dashboard/          // optional UI

One agent, many domains. Same notebook, same deploy. Onboarding a new skill is one PR.

[ IMAGE PLACEHOLDER ]
Diagram: a skill directory contributing four things (schema, CLI, instructions, dashboard) into the shared notebook
07.DECISION 3 Let the schema evolve from use

Decision three -- the hardest

## "I can't represent this"
is the most important signal.

Most agent stacks silently skip what they can't store. I treat schema rejection as a trigger for evolution.

The loop

Agent writes to TypeDB -- rejected ↓ Hook catches error, files GitHub issue ↓ Schema PR -- human reviews -- merge ↓ The graph grows from use, not from committee
[ IMAGE PLACEHOLDER ]
Circular diagram: agent tries -- schema rejects -- gap filed -- schema evolves -- agent succeeds
08.DECISION 4 Don't build an orchestrator

Decision four

## Use the runtime you
already pay for.

Claude Code IS the agent runtime. Skills mount via .claude/skills/. I don't ship my own orchestrator.

Tradeoff

Less control over the agent loop.

Win

~10x less code. Deploy is git clone && make build.

[ IMAGE PLACEHOLDER ]
Diagram: custom orchestrator (crossed out, complex) vs. Claude Code + skills (simple, three boxes)
09.WHY IT MATTERS The ontological distinction that pays off

An example

## Person vs. Role --
explicit ontology pays off.

LLM instinct

Author sub Person

Alice can't be an author, reviewer, and patient at once. Single inheritance breaks.

BFO / UFO pattern

Alice bears Author

Person is rigid. Role is anti-rigid. Roles come and go. Person stays clean.

This clarity only comes from making commitments explicit. LLM linguistic logic quietly bakes in errors you find at scale.

[ IMAGE PLACEHOLDER ]
Diagram: Alice with multiple roles attached via role-bearing relations (clean) vs. Author-sub-Person single-inheritance tree (broken)
10.IN PRACTICE Six skills, three domains, one notebook

What's deployed

## Same notebook,
different domains.

1 jobhunt -- positions, contacts, fit analysis
2 tech-recon -- comparative investigations
3 skill-builder -- design new skills
4 scientific-literature -- corpus curation
5 dismech -- disease mechanisms
6 literature-trends -- hypothesis tracking
[ IMAGE PLACEHOLDER ]
Screenshot: dashboard view -- jobhunt dossier or tech-recon investigation
11.OUTCOMES Results and honest lessons

Outcomes

## Results, and three honest open problems.

What worked

CAIS 2026 -- paper accepted at ACM Conference on Agents and Agent Systems

6 working skills across biomedicine, careers, and technical investigation

One codebase -- deploy is git clone && make build

What's still hard

Schema migration -- attribute changes still mean re-ingestion

Concurrent gap PRs -- two fixes can conflict

Proposed vs. committed -- no intermediate schema state yet

None of these are blocking. They're the next phase of work -- and they're the kind of problems that only emerge once the core architecture is working.

12.Q & A

## Any questions?

Gully Burns -- github.com/GullyBurns/skillful-alhazen