Pre-launch · taking design partners
The AI team behind your software.
All work in harmony.
Winnfield fills every role it takes to build, maintain and support a software product: support (tier 1 and 2), QA, product and engineering. Every role works from one understanding of your system, learned from your code, production data (read-only), logs and docs. It answers with the evidence, files the bug, fixes it, tests the fix against the same records, and builds the next feature.
Example · illustrative
Support asks
“Northwind’s exports stop at 1,000 rows since Tuesday. Bug on our side?”
Winnfield answers
Verdict: bug
Yes, a bug. Tuesday’s deploy capped export pages at 1,000 rows, and the job stops after the first page.
Evidence
3 production records · 2 files · 1 log query · 1 doc
- Exports
exp_7f3a,exp_7f3bandexp_80c1fororg_2210, 1,000 rows each (a read-only query) services/export/paginate.py:141→services/export/job.py:88/ecs/export-worker: “page_size capped at 1000”, 38 events since Tuesday- The docs, “Exports”: an export includes every matching row
Filed
ENG-4127, with the three record ids
Tested
exp_80c1 on the fix returns 4,212 rows (was 1,000). Passed.
Pull request
PR #2291 for your review. Nothing merged.
The same records, from answer to fix
Every role, one understanding
Support, tier 1 and 2
The customer’s question, answered in the thread with the customer’s own records behind it, and whether it’s a bug, a setting or a feature request.
QA and testers
Every fix arrives with the verifier’s result against the records from the incident, including anything it couldn’t reproduce. You’re checking a result, not a promise.
Product managers
Feature requests arrive as stories with acceptance criteria for each repository, and the product questions asked, not guessed.
Engineers
Tickets arrive with the causal chain, file:line and the record ids. Fixes arrive as pull requests on a feature branch. You review and merge; it never does.
Included in select plans
A support desk in your product
Add Winnfield’s chat widget to your product, and your signed-in customers get answers where they already are. Its first-line assistant answers from your documentation, which Winnfield writes and keeps current from your code. What it can’t answer, it hands to Winnfield in an internal note. Winnfield investigates your code, configuration and data (read-only) and briefs the assistant, which then answers your customer. Your team sees every conversation in the inbox and can step in at any time. When it’s a bug, your team files it with a click, and the rest of your AI team takes it from there: fix, tests, pull request.
How it works
01
Learn your system
It reads your code, production data (read-only), logs and docs. It works out how to install, build, test and run your system, and writes a Runbook you can read and correct. Every team’s work starts from it.
02
Answer
Support, QA, product and engineering ask in Slack or Jira. Every claim cites the file and line, or the production record, it rests on. Every answer ends in a verdict: a bug, a setting, a missing feature, or not knowable yet.
03
File
A bug becomes a ticket with the causal chain and the record ids. A missing feature becomes a story with acceptance criteria for each repository. A setting goes back to support with the exact change.
04
Fix, test, build
It fixes the bug on a feature branch and tests the fix against the records the ticket cited. It builds features to their acceptance criteria. Your engineers review and merge.
Trust, earned in stages
Each stage stays off until the one before has a week of clean numbers.
Stage 1
Shadow
Two weeks of private answers your team rates.
Stage 2
Answer
Replies where your teams ask. Read-only.
Stage 3
File
Bugs and stories with their evidence. You confirm each one at first.
Stage 4
Build
Fixes, tests and features on feature branches. Your engineers review and merge.
AI agent security, as built
Each of these is enforced by the architecture.
What Winnfield can reach, what it keeps, and what it never holds
- Your own network and key. Each customer gets its own VPC, its own egress address and its own encryption key.
- Read-only by grant. The production database credential can’t change your data, by its own grants, measured when you connect it.
- No agent can push or merge. The push credential never reaches an agent’s session. Every change is a pull request your engineers review.
- Our operators can’t read your data. Winnfield’s operators see metadata only, and every look is audited.
- A fresh machine for every job. Anything that runs your code runs in a virtual machine destroyed when the job ends.
Early access for design partners
Winnfield is pre-launch. Proofground, our sister company, is our first design partner. We’re taking a few more teams: founder-led onboarding, your hardest old escalation answered first, and a direct line to the people building Winnfield.