Questions about Winnfield
Find out who Winnfield is for, what it reads and never writes, what it needs from you, and how early access works.
The product
Who is it for?
It’s for companies whose product is an AI agent, whether that’s a voice or chat agent or an AI that does a task, such as reviewing code for security. It’s built for their engineering leaders, typically a CTO or VP of Engineering. It works in Slack, GitHub, and Jira Cloud or Linear.
What does Winnfield do?
Winnfield is an AI support and engineering team for companies whose product is an AI agent. It does the work of a company’s whole support and technical team: tier-1, tier-2 and tier-3 support, the AI and software engineers who find and fix the problem wherever it is in the product, whether in the AI agent or anywhere in the software around it, and the test engineer who checks the fix. When your agent does or says the wrong thing, it finds out why, then fixes it, tells support which setting to change, or builds the missing feature.
Requests reach it in four ways. Your own people, from support and engineers to product managers and executives, ask it in Slack to triage a bug, fix one or build a new feature. Someone can also assign it a Jira ticket. Your customers can ask it in Winnfield Chat, an optional support chat for your app or website. And scheduled checks, which your team defines or Winnfield suggests, run on a schedule and look for problems in your logs and events, records of things that have already happened, such as a finished call or a booking. Scheduled checks start once your admin turns on Build, the last of Winnfield’s four stages, because looking for problems nobody has asked about needs the most trust.
To find out why, Winnfield looks at your code, your logs and the agent’s conversations or outputs, and it has read-only access to your production data. It answers with citations to the records it read, or says it can’t tell.
Then it works out what’s needed. That may be a fix to the agent’s prompts, tools or model settings, a fix in the software around it, a change to that customer’s configuration, or a new feature. A configuration problem goes back to support with the setting to change, and support can fix it without an engineer.
For a bug, it files a Jira ticket with the evidence. Once someone assigns it the ticket, it fixes the bug on a branch with tests and tests the fix on the case’s own records. For a feature, it drafts a story, a Jira ticket with acceptance criteria, and asks your product team its open questions. It files the story once they’re answered, and builds the feature when someone assigns it the story, showing it working on the staging database. Your engineers merge every change.
How it works, from what your agent got wrong to a tested fix
Why don’t our alerts catch what our agent gets wrong?
Because its worst failures don’t crash anything. The agent still answers, but the answer is wrong, whether the cause is in the agent or in the software around it.
So Winnfield reads your code, records and logs alongside the agent’s conversations or outputs. You can also set up scheduled checks, which run on the schedule you choose and look for failures nobody has reported. They start once your admin turns on Build, the last of Winnfield’s four stages.
Why not just use Claude with MCP servers?
You can connect a general assistant to your systems. What MCP gives an assistant is access. Winnfield adds the checks that an MCP setup leaves to you. It confirms that every cited record was really read, and when it says a problem is a wrong setting, it checks that against your docs. Winnfield keeps its notes on how your system runs in the Runbook, which you review. It checks the Runbook before using it and marks any unverified steps. It also tests fixes against the records the Jira ticket cites.
The product is those checks, the Runbook, and a setup in which the machine that runs your code never holds a production credential.
What happens when it isn’t sure, or when it’s wrong?
When it can’t tell, it says so. Its answer files nothing and lists what it checked, what was missing, and what would settle the question.
When it’s wrong, give the answer a 👎 in the thread, and Winnfield asks what was wrong. In one click, the correction can go into your Product Brief, the one-page description of your product that Winnfield drafts during setup and your admin can edit. A Jira ticket filed on a wrong conclusion can be withdrawn from the same thread.
Winnfield counts the answers your team flags as wrong and shows you the count. It works in four stages. It starts in Shadow, and your admin turns on the other three, Answer, then File, then Build, one at a time in Winnfield’s web app, and can turn on the next stage only after a week with no answers flagged as wrong.
Does it find failures nobody has reported?
Yes, through scheduled checks. These are checks your team defines, or that Winnfield suggests from what it knows about your product. Your company’s admins set them up in Winnfield’s web app. Each one runs on the schedule you choose, reads your logs and events, and looks for a specific kind of problem.
When a check finds a problem, it takes the action you’ve set. It can file a Jira ticket for your team, file one and assign it to Winnfield, which starts Winnfield’s work on it, or alert a person. Scheduled checks, whatever their action, start once your admin turns on Build, the last stage. A bug is filed only if it meets Winnfield’s three conditions for filing, and only if that check is set to file Jira tickets.
Where do we set all this up?
In Winnfield’s web app, which is for setup and review. Your company’s admin turns on the stages there, sets up scheduled checks, and edits the Runbook and the Product Brief. If you use Winnfield Chat, your team handles its support tickets and approves its help articles there too. Day to day, your people ask Winnfield in Slack.
Security and data
Does Winnfield write to our production database?
No. Winnfield reads production through a role that your DBA creates with read-only grants. We generate the exact grant statement for your database engine and test the credential’s privileges when you connect it. The read-only limit is enforced by your database, not by a prompt.
Can it push to main or merge?
No. Every code change arrives as a feature branch with a pull request, which your engineers review and merge. Winnfield never merges. It pushes only feature branches, and your branch protection still applies. The credential that pushes a branch never enters the environment where the AI works.
Do you keep our production data?
We query production read-only. The evidence an answer cites can persist, encrypted, in its notes and Jira tickets. When we host Winnfield, the production data it reads while learning your system is deleted within eight days of that learning run. In your own cloud, records stay in your own bucket.
Can it run in our own cloud?
Yes. Winnfield’s runner, the component that runs its jobs, can run in your own AWS, Google Cloud or Azure account, inside your network, instead of ours. Your credentials then stay in your own secret store and your records in your own bucket, but what the runner reads to work on a question passes through Winnfield’s server in transit. The runner connects out and runs only a fixed set of operations, and each one is logged in your account.
Which certifications do you hold?
None yet. Winnfield holds no SOC 2 report or ISO 27001 certification. We’ll fill in your security questionnaire, and you can talk to the engineer who built the isolation.
Setup
Does it fit our stack?
Works with
- Code: GitHub, through Winnfield’s GitHub App
- Team chat: Slack, where your own people ask Winnfield for help
- Trackers: Linear, or Jira Cloud on Standard, Premium or Enterprise with Rovo
- Docs, optional: Confluence, Notion or Google Drive
- Databases: Postgres, MySQL and MariaDB, MongoDB, SQL Server, DynamoDB, BigQuery and Snowflake, through a read-only role
- Logs: your cloud’s own logs on AWS, Google Cloud, Azure or elsewhere, through a read-only credential scoped to logs
- Your agent’s conversations or outputs: read-only, where your product keeps them, whether in your database or your logs
- Languages: any, such as Go, Python, Ruby on Rails, .NET or Java
- Services your code calls: test-mode keys only, and live keys are refused
- Where it runs: our cloud, or your own AWS, Google Cloud or Azure account
- Your current help desk: keep it and have your team ask Winnfield in Slack or Jira, or add Winnfield Chat, the optional support chat for your signed-in customers, included in some plans, which aren’t published yet
What does it need from us?
It needs Slack, your code on GitHub, and either Jira Cloud or Linear. Jira Cloud must be on Standard, Premium or Enterprise, with Rovo, Atlassian’s AI, turned on, because Winnfield works inside Jira as a Rovo agent. It also needs a read-only role on your production database, a disposable staging database, and a read-only credential for your cloud that is scoped to its logs. Read-only access to your docs is optional. For the third-party services your code calls, it needs test-mode keys. When we host it, the machine that runs your code never holds the production credential.
Which Jira plans work?
Winnfield works with Jira Cloud on the Standard, Premium or Enterprise plan, as long as Rovo, Atlassian’s AI, is turned on and Winnfield’s agent is allowed in your Jira projects. Rovo is needed because Winnfield works inside Jira as a Rovo agent. Each time Winnfield works on a ticket, it uses your organization’s Rovo credits.
Do we write prompts or a knowledge base for Winnfield?
No. You review the Runbook, Winnfield’s notes on how your system runs, and the help articles it drafts for Winnfield Chat.
You also approve access rules and, if you use Winnfield Chat, connect it so that your backend signs each user’s identity.
Which databases does it read?
It reads Postgres, MySQL and MariaDB, MongoDB, SQL Server, DynamoDB, BigQuery and Snowflake, each through a read-only grant or role.
Winnfield Chat
Is Winnfield Chat in every plan?
No. Winnfield Chat, the optional support chat for your customers, is included in some plans. Plans and prices aren’t published yet, and we agree terms with each design partner.
Does Winnfield Chat’s AI see our code or data?
No. Winnfield Chat’s AI sees approved articles and navigation links, messages that customers can see, and user details your product supplies. It never sees internal notes. Only Winnfield’s read-only investigation touches your code and data.
Can Winnfield write to our customers?
Only through Winnfield Chat. Winnfield writes internal notes for your team, which your customers never see. Winnfield Chat sends a customer the part of a note marked safe to share, after your team approves it or, on topics your staff have turned on, automatically, after the required checks. Topics are the subjects your staff tag in your help articles. Your staff can also reply directly.
Pricing and early access
How is it priced?
Plans and prices aren’t published yet. Winnfield Chat, the optional support chat for your customers, is included in some plans. We agree early-access terms with each design partner, one of the first companies to use Winnfield before it launches, and requesting access commits you to nothing.
What happens after we request access?
We review your request and reply. Then we have a short call about your stack and one hard escalation. If it’s a fit, you become a design partner and the founder onboards you. Then, for two weeks, your team rates the answers Winnfield drafts privately.
Join early access as a design partner and bring us your hardest escalation.
A design partner is one of the first companies to use Winnfield, before it launches. An escalation is a customer problem your support team had to pass to engineers. Requesting early access is how you apply. The founder leads your onboarding, and requesting access commits you to nothing.