The result is a software change.
Make the repository legible. Specify bounded tasks, isolate execution, check behavior and review the design, so every merged change is one your team understands.
Inspect an agent-built codebaseOur engineering method
Harness engineering.
Build with agents.
Keep engineering accountable.
A harness gives an agent its working context, tools, execution boundaries and feedback. We engineer that environment so implementation produces work a team can inspect, accept and maintain.
We build this way on every engagement, and your engineers keep the harness when we hand over, so the speed stays with your team.
The software construction loop
01 / A bounded task
Define the outcome, acceptance criteria and exclusions. Prepare the repository context and allowed tools.
Two related responsibilities
Building with an agent is not the same as shipping one.
The result may be a business action.
An agent product needs runtime permission boundaries, capability contracts, evaluations and recovery. A capability contract defines an operation’s preconditions, allowed effects and returned evidence; enforcement must live in the system.
Explore agent runtime engineeringThe inspection framework
Six questions before more autonomy.
Apply them to a code change or a runtime action. The questions carry across; the controls and consequences differ.
- Outcome
- What useful result must the work deliver, and what would make us reject it?
- Context
- Which source, constraints and current state does the agent need?
- Authority
- What may it read, change or execute? Who can approve the next commitment?
- Evidence
- Which observations demonstrate behavior, acceptable design and the permitted path?
- Budget
- What limits apply to attempts, compute, elapsed time and human review?
- Recovery
- How do we stop, resume or reconcile work that ends partway through?
Worked example
A working export. An inspectable decision.
The task sounds simple: export customers to CSV. The contract is more specific. Only an authorized administrator may export active customers from their own tenant, with exact fields and a bounded output. An error must never become a partial download.
We made those rules explicit, implemented the change through the harness and checked the result against every one of them. The handoff is the contract, the code and the evidence together.
Includes the source, test fixtures, 24 tests and a one-line verification command that runs on any laptop.
The verification record
The right rows. Within the right boundary.
- 01Authorize
Session, role and permission before the read.
- 02Select & bound
Active rows from one tenant. Exact fields and output limits.
- 03Verify & decide
Inspect the output and every rejected case.
24 tests passed6 existing-list + 18 export tests
The contract and observed output
- Request
GET /customers/export- Authority
- Authenticated fixture session, administrator role and export permission, checked before reading customers.
- Membership
- Active customers belonging to the authenticated tenant, ordered by customer_id.
- Bounds
- 1,000 data rows and 1,048,576 UTF-8 bytes, including the header. Exceeding either refuses the whole download.
customer_id,name,email
a-101,"North, Branch",north@example.test
The CSV preserves accepted field values, including quoted commas and embedded lines, and rejects formula-like prefixes that could execute in a spreadsheet.
Verification and counterexample
Check what must not happen.
We planted a deliberately unscoped version that returned another tenant’s row. The exact-membership check caught it; restoring the tenant-scoped implementation passed.
- Session, administrator and export permission required before customer read.
- Exact membership and fields, second tenant, active-only selection.
- Client headers cannot change identity or permission; all query parameters refused.
- Quotes, commas, embedded lines and ordinary leading spaces round-trip.
- Scoped formula-prefix policy applies to every exported field.
- Empty export includes header; export is not just the first list page.
- Exact row limit and encoded-byte limit, including CSV header.
- Database failure and exceeded bounds produce no partial download.
- Only GET supported; existing list behavior preserved.
A second example: this website’s contact API
Check the effect, not just the response.
A valid, verified inquiry should reach the email function once. Failed verification must not call it. An email-service error must not return a false success response.
The handler tests check the HTTP result and the email call together, so a green response always means the message was handed off.
What your team inherits
The software, and the means to keep changing it.
The handoff is planned before implementation starts. Your team owns the harness, or keeps us on a monthly retainer to run and improve it with you.
Repository context
Project guidance, architecture decisions, task conventions and the commands needed to build and check the software.
Verification & review
Project-specific tests, acceptance gates and review packets tying the change to its evidence and remaining risks.
Operation & recovery
Agreed workflows, configuration, runbooks and the procedure for handling an interrupted or failed run.
Ownership & access
Named maintainers, client-approved accounts and a rehearsed handoff, or a monthly retainer if you want us to keep running it.
When to bring us in
Your team has the tools. Now make the workflow work.
A growing review queue, unclear agent permissions or repeated rework is the signal. Pick the starting point that fits.
Build together.
A forward-deployed team sets up the harness and ships real features through it with your engineers.
Discuss a buildReview the current setup.
Inspect repository context, permissions, verification, review load and architecture drift before deciding what to change.
The harness reviewKeep it current.
Models and coding agents change monthly. A retainer keeps your harness, permissions and gates current, with a fractional CTO for the leadership decisions.
Forward-deployed operationsStart a conversation
What are you building—or deciding?
Tell us where you are. We reply within one business day, and the first conversation ends with a recommended next step.