I build AI agents by asking an old question: whose agent are they?
I use coding agents every day, from the principal side of the relationship. What I think AI agents should be — and what they should refuse to do — comes from that experience, then from law, economics, and literature.
You learn what a good agent is by being responsible for what a bad one produces.
The repositories below are small, opinionated answers to the question of for whom an AI agent acts. Each has a defined principal, a bounded scope, and a refusal to substitute its judgment for the principal's.
An agent for the contract reviewer, not the drafter.
It is built for the moment when a clause feels risky, but the reviewer cannot yet say exactly why. It turns that vague concern into structured verification questions.
It does not decide whether a clause is legal, enforceable, fair, risky, or safe to sign. It also refuses to force generation when the input is outside the contract verification-question task.
Principal: contract reviewer
Artifact: verification questions
Boundary: no verdict, no forced generation
Release: v1.0.0
An agent for the domain reader trying to make sense of noisy trend signals.
It is built for the moment when something feels current, dated, coherent, or off, but the reader cannot yet say what rule explains that judgment.
It does not recommend what to wear, buy, publish, or believe. It turns canonical and emerging signals into interpreted rules, conflicts, gaps, tradeoffs, and visual references while keeping the reasoning structure visible.
Principal: domain reader / decision-maker
Artifact: interpreted rules and reference frames
Boundary: no prescription
Release: v1.0.0
A technical publication for the AI system builder trying to make agent failures visible, inspectable, and repairable.
It is built for the moment when an agent system works in a demo, but no one can tell where the failure lives. It turns that ambiguity into essays about responsibility boundaries, state, runtime design, controlled context, and observable failure.
Principal: AI system builder
Artifact: essays and implementation proofs
Boundary: no framework ownership, no vague agent magic
- LLMs as controlled transformation components, not the center of the system: reasoning structure belongs in retrieval, schemas, reflection, checkpoints, and workflow state.
- Structure as engineering substrate, not the surface the user reads.
- Decision-grade artifacts over confident answers: questions, rules, traceable evidence, and reference frames.
- Explicit state machines over open-ended loops when reproducibility, attribution, and debugging matter.
- Abstention as a feature: a useful agent must know when not to answer.
- No-disclaimer-by-design: the agent avoids judgments that would require warning users not to trust them.
- Provider contracts over provider lock-in: typed boundaries, observable workflows, and replaceable infrastructure.
- Visible responsibility boundaries over framework ownership: agent frameworks are useful, but they should not become the architecture.
- AI tools as principal-bounded delegation: I use coding agents daily, and the boundaries I demand from them are the boundaries I build into mine.
I am working toward Georgia Tech OMSCS to restate these commitments in more formal ML and systems language: calibrated abstention, frame-lending representations, controlled transformation pipelines, and agent workflows with explicit decision boundaries.
Applied AI engineering in domain-heavy contexts. The thesis above is what I have come to think after trying to make LLMs useful inside real workflows without making them the center of those workflows.
My formation crosses two traditions: a liberal arts background and ongoing graduate study in computer science. The questions about agency, representation, and the structure of judgment in this portfolio come from the first; the way they are implemented as schemas, state machines, and typed pipelines comes from the second.
I am interested in where AI agents should stop — and how that boundary can be made explicit in code.