Capital One is putting agents to work on three different engineering problems. Context Specs organizes planning and implementation. VulnHunter finds and helps repair security defects. DataAgents produced rules for a large cloud-analysis project. Each workflow needs a different way to judge the result. The public record describes separate projects, not one bank-wide platform.
Planning work that several agents can carry out
Context Specs, released in June 2026, stores plans in files that later agent sessions can read. It divides a feature into ordered pieces, supplying the relevant code context for each. Three or more independent agents can review a specification in parallel. Implementation can also run in parallel when the plan's dependencies allow it, using separate Git worktrees: isolated working copies of the same repository.
Each piece declares a feedback signal, such as a test or endpoint check. That gives implementation a concrete stopping condition. Agreement among planning agents adds another perspective, but it does not establish that the specification matches the customer's need.
The count of three or more describes the documented review design. Capital One does not report the largest production run, its duration, or the number of concurrent implementation workers.
Security findings must survive a challenge
Capital One's VulnHunter announcement reports internal use across thousands of repositories and tens of business areas before its July 2026 public release. The workflow investigates possible attack paths, tries to disprove its own findings, and proposes focused repairs for engineering review.
The public repository separates hunting, repair, and verification. A repair workflow creates a failing security test, makes a fix, and checks for regressions. A separate verifier assesses the result. Batch tooling lets the same process cover multiple repositories. SWFT inspected the documentation; it did not run a security evaluation of the tool.
Repository coverage is useful evidence of reach. It does not reveal how many scans ran together, how many issues people accepted, or how much review work remained. Those are separate questions for anyone comparing this system with another security workflow.
Data rules need a domain expert
In Capital One's DataAgents account, an agent helped produce cloud-resource dormancy rules and Spark SQL queries for roughly 350 resource types. The author reports ten days of work against an initial estimate of six to nine months, including human validation.
Review caught wrong field names, nonexistent columns, and overconfident judgments. Some resources required usage telemetry rather than configuration alone. This is a useful limit: a query can run successfully while its business interpretation is wrong. The time comparison is a project estimate and result, not a controlled productivity study, and no agent concurrency is disclosed.
Choose the proof before expanding the work
SWFT reads these as three distinct acceptance problems:
| Work | Evidence to inspect | Human question |
|---|---|---|
| Feature planning | Requirements, dependencies, and review disagreements | Does this solve the intended problem? |
| Security repair | A reproducible defect, proposed change, and verification result | Is the repair sufficient and acceptable? |
| Detection rules | Executable queries plus checks against real domain behavior | Would this classification lead to the right action? |
For a first pilot, choose the row closest to an existing backlog. Agree on what counts as an accepted result, sample the difficult cases, and record the time spent reviewing and correcting them. Expand when that evidence supports it. A count of agents, repositories, or generated queries cannot answer those questions on its own.