/ Context
Enterprise AI applications share the same underlying concerns — deployment, tool access, guardrails, evaluation, observability — and none of them are the interesting part of the application. The Dev Harness exists so those concerns arrive as a paved path with reusable defaults, rather than being answered again in each repository.
/ Role & decision scope
- Built the Dev Harness: the templates, deployment automation, integration patterns and developer tooling are my delivery.
- Owned the harness architecture — what belongs in the paved path and where applications extend it.
- Set the default security guardrail, evaluation and observability posture that applications inherit.
- Authored the reference patterns that define how an AI application is structured on the harness.
/ Constraints
- Security guardrails have to hold as defaults, not as guidance an application can skip.
- Applications differ, so the harness has to leave room for application-specific extension.
- Evaluation and observability belong in the delivery path, not in a later remediation pass.
- The harness is a shared surface, so it has to stay coherent as applications diverge.
/ Architecture & key decisions
- D01
Paved path over policy documents
Security guardrails, observability and evaluation are wired into the templates and CI/CD pipelines themselves, so the compliant route is the default route rather than something an application has to add.
- D02
Tool access through MCP and shared integration patterns
Rather than each application inventing its own route to internal systems, tool access follows common MCP and tool-integration patterns provided by the harness.
- D03
Evaluation as part of delivery
Evaluation workflows ship inside the harness alongside deployment automation, so evaluating behaviour is part of building the application rather than a separate initiative.
- D04
Reusable defaults with explicit extension points
The harness supplies templates, pipelines and integration patterns as defaults; application-specific behaviour stays in the application, which keeps the paved path reusable.
/ Trade-offs
- Standard defaults versus application-specific needs
- Opinionated defaults for guardrails, deployment, evaluation and observability; deliberate room for applications to extend where their problem genuinely differs.
- Harness scope versus coherence
- Design focus: keep the harness to the concerns AI applications share, and leave problem-specific behaviour to application code.
- A bare starting point versus a production-shaped one
- Templates start with guardrails, evaluation hooks, observability and CI/CD already present, accepting a heavier starting point so production concerns are not retrofitted.
/ Evidence & outcomes
- Artifact
- Reusable AI application templates and reference implementations
- Artifact
- Deployment automation and CI/CD pipelines for AI services
- Artifact
- MCP and tool-integration patterns with security guardrails
- Artifact
- Evaluation workflows and observability wired into the templates
- Decision
- Reference patterns and platform standards defining how AI applications are structured