Context first.

FOUNDER PRINCIPLE / HUMAN + AGENTIC WORK

Before I decide what to build, I listen for the reality surrounding the request: the people, expectations, constraints, dependencies, and intended outcome.

Context is not a waiting room before development. It is the operating condition that makes responsible action possible.

I listen not only to what someone says, but to how they explain it, what they emphasize, and how much ownership they appear to have over the idea.

Confidence can be one signal of commitment, but it is not the only one. I am listening for preparedness, curiosity, openness to questions, and a willingness to participate in the process.

When an idea still contains gaps, I do not usually challenge it directly. I use a line of questioning that helps the person inspect their own reasoning. That process may lead them toward something they had not seen, or reveal that my original interpretation was incomplete.

The objective is not for me to take possession of the answer. It is to create the conditions for the idea holder to recognize, challenge, and ultimately own the decision.

These sources do not define my method. They provide adjacent frameworks for testing where it is useful, where it needs qualification, and where responsibility must remain explicit.

Dilemmas in a General Theory of Planning — Horst W. J. Rittel and Melvin M. Webber, 1973.

Relevance: complex problems cannot always be separated cleanly from the act of defining them. The formulation of the problem and the path toward a response influence one another.

SOURCE ↗

AI Risk Management Framework Core — National Institute of Standards and Technology.

Relevance: trustworthy AI work depends on establishing context, documenting roles and limitations, defining human oversight, and continuing to monitor the system as conditions change.

SOURCE ↗

A Practical Guide to Building AI Agents — OpenAI.

Relevance: reliable agent systems require clear instructions, well-defined tools, layered guardrails, intervention thresholds, and an iterative expansion of capability based on evidence.

SOURCE ↗

AI is involved from the beginning, but it should not simply be inserted into an operation and expected to understand it.

Every project introduces different people, information, permissions, risks, tools, and definitions of success. The core principles may remain consistent, but the operating environment must be tailored to the work.

I began calling the recurring process QDI in 2025:

Every project needs documentation. What changes is its density and architecture. Complex systems may require modular Doc Sets for distinct phases or paths. More design-led work may need a lighter structure, but it still requires an agreed purpose, constraints, and recorded decisions.

The goal is not to make an agent read everything constantly. It is to route the appropriate context to the appropriate part of the work when it becomes necessary.

#### Field Note 01 — Guidance through questions

If I notice a possible gap, I guide the conversation toward it through questions rather than announcing that I have found the answer.

Questioning works in both directions. It may reveal a weakness in the idea, or show me that I was seeing it incorrectly. Firm pushback becomes appropriate only after trust has established that I am there for the outcome—not to protect either person's ego.

#### Field Note 02 — The seed and the environment

Plan A does not have to remain frozen in its seed-stage form. As it grows, an unexpected branch may appear, early growth may need pruning, or the soil may require treatment before the idea can continue responsibly.

An apple tree will always be an apple tree, but its height, width, and fruit will be determined by the environment in which it grows.

The responsibility is not to preserve every early branch. It is to protect the identity and purpose of the work while allowing evidence to influence its form. If evidence disproves the original premise, we should admit that the project is no longer following Plan A rather than disguise a fundamentally different direction.

#### Counterposition — More context is not always better

Documentation can become its own form of drift. An AI system can repeatedly read, summarize, create, and reorganize documents without advancing the actual project. The system begins maintaining its description of the work instead of doing the work.

The useful threshold is reached when I understand what wants to be built, where it needs to arrive, and which credible lane can be entered next.

TEST / Does this information clarify a decision, expose a risk, or prepare the next implementation?

If it does none of those things, the work probably needs contact with reality rather than another document.

#### Boundary — Authority is conditional

AI may contribute equal pressure to the search for an answer, but it does not hold equal accountability.

Bad loops, repeated misunderstandings, unsupported assumptions, unexplained scope changes, and movement away from the approved outcome are reasons to reduce authority or stop implementation.

My first response is to inspect the operating environment: the instruction, available documentation, context routing, permissions, tools, and decision boundaries. The model can also fail through context loss, unsupported inference, nondeterminism, or connected-tool errors.

If the work has moved substantially off course, I stop it. The next step is to repair the context and re-establish alignment before continuing.

STATUS / AI authority is earned through evidence, bounded by the system, and reversible at any moment.

I do not attempt to eliminate uncertainty before building. I reduce it enough that the next action is intentional, bounded, and capable of teaching us something.

Discover → establish a lane → build → observe → update the context.

Discovery and development are not separate territories. Discovery establishes the next credible lane. Implementation produces evidence. Evidence changes what we understand.

The philosophy remains consistent even when the details carry different names.