What I’ve learned

Lessons earned by building, testing, and evaluating applied-AI systems.

Each Insight begins with a portable enterprise lesson. Technical depth and implementation evidence are available on demand.

Lessons from building

Three lessons shaping the reference architecture

The proving ground is specific. The architectural judgment is portable across organizations and industries.

Deterministic First. Models When Needed.

AI does not make every software problem an AI problem. I learned that applied AI engineering depends on choosing where probabilistic intelligence adds value—and where deterministic software is safer, faster, cheaper, and easier to govern. Enterprises need an architecture that supports model escalation for genuine ambiguity without forcing every task through an LLM.

What I learned

Specific learning: A source that initially appeared to require model assistance could be interpreted through a reusable deterministic pattern. The right response was to improve the deterministic capability while preserving a bounded escalation path.
Implementation evidence: The accepted real-source evaluation moved 21 source locations through normalization into 21 private Mapspring locations: 21/21 materialized, with zero missing, unexpected, or duplicate locations, zero model calls, and zero geocoding calls.
Enterprise implication: Treat model use as an architectural decision, not a default. Define escalation conditions, measure cost and uncertainty, and prefer repeatable software where it is sufficient.

AI Agents Need Boundaries, Not Just Tools.

Giving an agent more tools can make it more useful, but it also increases its authority and the consequences of error. I learned that enterprise agents need explicit boundaries around what they can access, call, change, and retain; how often they may act; and where a person must intervene. Capability without containment is not production readiness.

What I learned

Specific learning: Application-level browser restrictions were not enough. The workflow needed an independent network boundary, authorized-host checks, request and byte budgets, tenant binding, role enforcement, and safe stopping after failure.
Implementation evidence: Controlled testing denied direct network bypass, forbidden authorities, cross-tenant access, and insufficient roles. External content was treated as untrusted evidence; browser and network execution remained isolated and fail-closed.
Enterprise implication: Design identity, data access, tool authority, action budgets, human approval, and interruption as one connected control system—not separate features added after an agent works.

Production AI Is an Operating Model Problem.

Moving AI from a prototype into enterprise work requires more than a capable model and application code. I learned that authorization, human review, provenance, failure handling, environment separation, release controls, and progressive enablement determine whether intelligent work can be trusted. Production readiness is an operating discipline shared across technology, security, governance, and accountable leaders.

What I learned

Specific learning: Analysis and mutation need separate authority. Human acceptance should not imply publication, and production-capable architecture should not automatically grant production permission.
Implementation evidence: Switchkit creates private-before-publish artifacts, preserves execution provenance, rejects conflicting replay, enforces tenant and role boundaries, and retains a publication fence. Production execution remains disabled and fail-closed despite controlled-environment validation.
Enterprise implication: Use staged enablement: prove the workflow, constrain the environment, make actions idempotent and auditable, preserve kill switches, and expand authority only when evidence supports it.

Editorial standard

Evidence → implication → lesson

Insights remain practical, explicit about limits, and grounded in work that was actually built or evaluated. They separate demonstrated capability from future possibility.