Companies call it bias for action. Builders call it shipping early.

The principle is the same:

Run more experiments and the world will give directions.

It is easy to polish the product in your head.

People will want this next.
The workflow should be structured like this.
The feature should behave this way.
This edge case probably matters.
This part should be rebuilt before anyone sees it.

Maybe.

Until someone has run the experiment, it is an untested hypothesis.

That is the trap. The work feels productive because the team is still thinking, designing, debating, and improving. But before the product is in front of real users, many of those improvements are aimed at a target that may not exist.

Optimization is only useful when the target is real.

The product in your head is not the product in the user’s hands

Before users touch a product, the builder has a clean version of the workflow in mind.

The user has a problem.
The product explains what it does.
The user understands the next step.
The feature creates value.
The workflow continues.

That is the imagined path.

The real path is usually messier.

A user hesitates on a step the team thought was obvious. They ignore the feature that felt central. They try to use the product for something adjacent but more painful. They ask a question the interface should have answered. They create a workaround that reveals the real job to be done.

That is where the useful information is.

Not in the abstract version of the product. In the moments where the product meets the user’s actual context.

This is why shipping early matters.

Not because quality does not matter.

Quality matters a lot.

But the first version is not supposed to prove you were right. It is supposed to show you what is true.

A rough product in front of real users will teach you things another week of internal debate cannot.

Feedback changes the target

A common mistake is treating feedback as something that improves the current plan.

Sometimes it does.

More often, feedback changes the plan.

The team may think the problem is speed. The user may care more about confidence. The team may think the key feature is automation. The user may need better control. The team may think the workflow starts with a blank input. The user may actually start from an artifact, a document, a spreadsheet, a ticket, or a conversation already in progress.

Those differences matter because they change what the product should become.

A good feedback loop does not just answer:

How do we make this version better?

It also answers:

Are we solving the right problem in the right shape?

That is a different question.

The first question creates polish.

The second creates product judgment.

Watch what users do

Users are often better at revealing problems than describing solutions.

That is not a criticism. It is just how product discovery works.

A user may ask for a button, but the deeper signal is the repeated action behind the request. They may ask for an export, but the real issue is trust, review, or handoff. They may say the system is confusing, but the important detail is the exact point where their mental model broke.

Watching the user matters because behavior carries information that summaries miss.

You find out:

• where they hesitate
• what they skip
• what they repeat
• what they misunderstand
• what they try before asking for help
• what they expected the product to know
• what work they still do outside the product
• what would make the next attempt easier

Those are not cosmetic details.

They are instructions from reality.

Ship small enough to learn

The goal is not to ship something careless.

The goal is to ship something small enough to learn from.

A useful early version should be narrow, honest, and observable.

Narrow, because a broad product creates too many ambiguous signals. If everything is possible, it becomes harder to tell what actually matters.

Honest, because the product should not pretend to be more mature than it is. Early users can tolerate rough edges if the value is clear and the boundary is explicit.

Observable, because the team needs to understand what happened. Where did users slow down? What did they try? What failed silently? What surprised them? What did they ask for after the first attempt?

The point of the first version is not completeness.

The point is contact.

You want the smallest useful product that can survive a real interaction and produce real signal.

The AI product version

This matters even more for AI products.

A model can be capable and the product can still be wrong.

The model may answer correctly, but the answer may arrive at the wrong point in the workflow. It may produce a useful summary, but not the evidence a reviewer needs. It may automate a task, but remove the control that makes the user comfortable trusting the result. It may make a demo look impressive while still failing the messy path where real work happens.

The hard part is not only whether the system can produce an answer.

The hard part is whether it helps a real person make progress.

That means the product has to learn from contact with real users:

• what context they actually have
• what uncertainty they need surfaced
• what evidence they trust
• what decisions they are trying to make
• what failure modes they can tolerate
• what parts of the workflow should stay human
• what output is useful enough to change the next action

Those details rarely become obvious from a whiteboard.

They become obvious when someone tries to use the system and gets stuck.

Capability is not the same as fit

A lot of AI products start from the question:

Can the model do this?

That question matters, but it is incomplete.

The better product question is:

Can this system fit into the user’s workflow well enough to change what happens next?

That is where many products break.

The capability exists, but the workflow fit is weak. The output is impressive, but hard to inspect. The interface is flexible, but does not guide the user toward the right action. The system works in the happy path, but does not expose uncertainty, missing context, or failure clearly enough for real use.

In high-trust workflows, this gap becomes even more important.

The product has to preserve human judgment. It has to make evidence visible. It has to help the user understand what changed, what is missing, and what should be reviewed.

That kind of fit is hard to design from a distance.

You have to watch the work happen.

Optimize after reality responds

There is a time to optimize.

Once the team knows what matters, optimization becomes powerful. Speed matters when you know which step blocks the workflow. Interface polish matters when you know which decision the user is trying to make. Automation matters when you know which repeated action is actually painful. Reliability matters when you know which failures users cannot tolerate.

Before that, optimization can become a way to avoid learning.

It can keep the team busy while delaying the moment of truth.

The better sequence is simple:

1. Form a hypothesis.
2. Ship the smallest useful version.
3. Watch real users interact with it.
4. Identify what reality made obvious.
5. Optimize against that.

The product improves because the feedback loop is tight.

The team is no longer guessing from inside the building. It is learning from contact with the environment the product is supposed to serve.

The broader lesson

Product judgment is not just having strong opinions.

It is knowing how quickly to let reality update those opinions.

That requires shipping before every detail feels settled. It requires watching users without defending the product in your head. It requires treating confusion, hesitation, and workarounds as signal instead of embarrassment.

Do not over-optimize before you know what matters.

Ship the smallest useful version.

Watch what users actually do.

Then optimize against the real world.

The useful part was not the award. It was the technical question the prototype forced:

What should exist around a model before it can safely help with high-trust administrative work?

FieldDesk is my answer to that question in one workflow.

It is not a regulation chatbot. It is an agentic workflow system that takes mission intent, searches controlled sources, maps evidence to requirements, catches gaps, runs deterministic checks, and produces a review-ready action package for a human.

The product surface is military administration. The technical pattern is broader:

controlled sources
  -> tool-using agent
  -> structured extraction
  -> deterministic verification
  -> source-backed workflow state
  -> human-review package

That is the layer around the model.

The hackathon context

The event was SCSP’s 2026 National Security Technology Hackathon, hosted as part of the AI+ Expo ecosystem. SCSP describes the hackathon as bringing together AI engineers from academia, research institutions, the private sector, and government to build applications for national competitiveness and national security.

The first phase took place across San Francisco, Boston, and Washington, D.C. Teams built prototypes in tracks including Cloud Laboratories, Electric Grid Optimization, Wargaming, and GenAI.mil. FieldDesk won the GenAI.mil track for the Washington, D.C. first phase. The GenAI.mil track focused on AI tools for military administrative work, logistics, and tactical knowledge retrieval for rank-and-file users.

That framing was useful because it constrained the build. The prototype had to target a concrete user, a concrete workflow, and a concrete failure mode.

The workflow

The first workflow is TDY travel readiness.

A user enters mission intent:

Send 10 soldiers to Demo Training Site for training from June 10-14. Lodging and rental vehicles required.

FieldDesk turns that sentence into structured workflow state:

workflow: TDY travel
purpose: training
destination: Demo Training Site
dates: June 10-14
travelers: 10
lodging: required
rental vehicles: required

Then the agent searches mocked sources that represent the systems a real workflow would touch:

• coordination messages
• document repositories
• rosters
• training orders
• GSA-style rate data
• JTR-style policy excerpts
• local SOPs and unit checklists
• uploaded corrections
• DTS-style export fields

The initial run intentionally contains problems:

• the mission says 10 travelers, but the roster only shows 8
• no funding memo is present
• the rental vehicle justification is too generic for review

FieldDesk surfaces those as review blockers before the package reaches a human reviewer. After the user stages corrections, the system recomputes readiness and generates a package with evidence map, reviewer objections, action list, packet summary, export rows, and source-backed trace.

FieldDesk synthetic demo. The screenshot shows the final readiness package after corrections are staged: evidence map, reviewer notes, deterministic per diem verification, workflow progress, and export-oriented fields. All visible data is synthetic.

The core value moment is simple:

catch avoidable administrative failure before review.

The architecture

The prototype is a TypeScript / Next.js application with a controlled agent runtime.

The important design choice is the boundary between semantic reasoning and deterministic verification.

intent
  -> source selection
  -> agent tool loop / synthesis
  -> structured output schema
  -> deterministic rules
  -> validated workflow object
  -> review package

The model owns semantic work:

• interpreting mission intent
• choosing relevant source tools
• extracting facts from documents and messages
• identifying gaps and conflicts
• drafting reviewer objections and next actions

The application owns system controls:

• which sources are available
• which corrections have been staged
• which tools the agent can call
• schema validation
• per diem arithmetic
• audit trace construction
• final API contract

This boundary matters because high-trust workflows should not put all correctness inside the model. The model can reason over messy context, but the platform should control what data exists, what tools can run, what math is trusted, what output shape is valid, and what a human can inspect.

A model response is not a workflow state.

A workflow state needs source references, typed fields, validation, deterministic checks, and a path to human review.

Tool use over open-ended chat

The autonomous path uses fixture-backed tools instead of open-ended search.

That was intentional. In the public prototype, the tools are mocked. In a real environment, the same boundary would represent approved connectors into systems such as email, document stores, policy references, rate tables, and workflow systems.

The agent loop is bounded:

1. The model chooses a tool call.
2. The API validates the tool arguments.
3. The tool executes against controlled fixture data.
4. The observation is appended to agent state.
5. The loop continues until the model returns a final synthesis or reaches a step limit.
6. The final object passes schema validation and deterministic checks.

That is a different product shape from a blank chat box.

A blank chat box asks the user to know what to ask. FieldDesk asks the system to know what the workflow requires.

Deterministic checks outside the model

Some parts of the workflow should not be delegated to the model.

Per diem arithmetic is one example. FieldDesk lets the model extract trip facts and reason over evidence, but the application verifies rate calculations using deterministic rules.

That pattern generalizes:

• let the model interpret messy language
• keep arithmetic in code
• keep source availability explicit
• keep output schemas strict
• keep human-review artifacts inspectable

The goal is not to distrust the model. The goal is to put the model in the right part of the system.

Scaling across the Department

The TDY workflow is only one instance of a broader pattern.

The scalable version of FieldDesk is not one central team hard-coding every administrative process. It is a workflow layer where units can create, improve, and share operational workflows with each other.

A battalion that has already encoded a good travel-readiness workflow should not force every other battalion to rediscover the same checklist, source mapping, reviewer objections, and export fields. The useful artifact is not just the completed packet. It is the reusable workflow:

workflow template
  -> required sources
  -> extraction schema
  -> deterministic checks
  -> reviewer questions
  -> export format
  -> local unit adjustments

That makes the system compounding. One unit can build a workflow for TDY packets. Another can adapt it for equipment turn-in. Another can encode a recurring training-readiness process. Over time, this points toward a Department-wide library of source-backed workflows that preserve local context without making every unit start from a blank chat box.

The important governance boundary is that shared workflows should be inspectable before they are adopted. A unit should be able to see what sources a workflow expects, what fields it extracts, what checks it runs, what assumptions it makes, and where human approval remains required.

The end-state product thesis is not a single giant assistant. It is a shared workflow graph for administrative readiness: reusable enough to spread across units, local enough to adapt to mission context, and structured enough to keep evidence and accountability intact.

Evaluation

FieldDesk includes a small evaluation harness around the demo workflow.

The evals use a golden scenario for the TDY case and check both exact fields and semantic quality:

• exact checks for structured fields like dates, travelers, and estimated totals
• expected initial output before corrections
• expected corrected output after staged fixes
• tool-loop tests for source retrieval behavior
• deterministic-rule tests for calculation logic
• LLM-as-judge grading for groundedness and reasoning quality

This is still a hackathon prototype, so the evals are small. But the principle matters.

For operational AI, evaluation has to move closer to the workflow. It is not enough to ask whether the model can answer a policy question. The system has to be evaluated on whether it helps a user produce a better package under realistic constraints:

• Did it find the right sources?
• Did it expose missing evidence?
• Did it distinguish weak evidence from strong evidence?
• Did deterministic checks catch errors?
• Did the final package help a reviewer inspect the decision?

Those are systems questions, not only model questions.

Why this matters

Administrative work is easy to dismiss because it looks like paperwork.

But paperwork is often how organizations coordinate action. It decides whether people move, equipment arrives, travel happens, funding is available, permissions are granted, and plans become executable.

If that layer is slow, the organization is slow.

The right AI system should compress the evidence surface without hiding accountability. It should preserve sources, surface gaps, and help humans make better decisions faster.

That is why FieldDesk is not framed as “automating paperwork” in the simplistic sense. The technical goal is administrative readiness:

less hunting
less rework
clearer gaps
typed workflow state
source-backed outputs
human-reviewable packages

Scope and safety

FieldDesk is a hackathon prototype, not a production military system.

The public repository uses synthetic demo data only. It does not include personal records, credentials, operational records, or government output. The connectors are mocked to show the workflow pattern without requiring access to production systems.

That constraint is intentional. The public demo is meant to make the product shape inspectable:

• agent-led evidence gathering
• controlled tool use
• structured extraction
• gap detection
• correction staging
• deterministic verification
• reviewer-ready output

The real work would be integrating the same patterns into approved environments, approved data sources, and accountable review processes.

What I learned

The strongest AI products for government will probably not look like generic assistants.

They will look like workflow systems with models inside them.

The model will reason, but the product will define the task boundary. The product will decide what sources exist, what evidence counts, what output schema is valid, where uncertainty is shown, what a reviewer can inspect, and which actions require human approval.

That is the thread connecting FieldDesk, ATO Copilot, and the systems I keep building:

high-trust work needs source-backed AI, not just fluent AI.

The bottleneck is shifting from access to model capability toward the ability to wrap that capability in systems that preserve evidence, judgment, and accountability.

FieldDesk is a small prototype pointed at that shift.

The prototype is public here: https://github.com/EthanHNguyen/FieldDesk

Sources: SCSP Hackathon, AI+ Expo Hackathon, FieldDesk repository.

That sounds obvious, but it is easy to forget when the most visible progress in AI is measured through demos, benchmark scores, and model launches.

Those things matter. Capability matters. A stronger model expands the frontier of what is possible.

But capability by itself does not create operational value.

A model can answer a question once and still fail as a system. It can produce an impressive demo and still be hard to evaluate, recover, audit, or trust. It can be powerful in isolation and brittle inside a real workflow.

The interesting work is no longer just proving that frontier models are capable. That part is increasingly obvious.

The hard part is turning capability into systems people can depend on.

The missing layer

Between model capability and real-world value, there is a systems layer.

That layer includes:

• infrastructure that can serve models reliably
• evaluation loops that catch behavior benchmarks miss
• interfaces that make uncertainty and provenance legible
• retrieval and data systems that ground outputs in context
• observability that shows when the system is failing
• recovery paths when the model, tool, or user workflow breaks
• trust mechanisms that let humans stay accountable

This layer is where a model becomes useful.

It is also where many AI systems fail.

Not because the model is weak. Because the surrounding system is not designed for the environment it enters.

Capability is not reliability

A frontier model can be impressive and unreliable at the same time.

It may solve a hard problem in one context and miss a simple constraint in another. It may produce a plausible answer without enough evidence. It may follow instructions correctly but fail to expose the assumptions behind its output.

In low-stakes settings, that may be acceptable. The user can retry, ignore the answer, or treat the model as a brainstorming partner.

In high-trust workflows, that is not enough.

A useful system should be able to answer:

• Where did this claim come from?
• What evidence supports it?
• What changed since the last run?
• What is missing?
• What should a human review?
• What happens if the model is wrong?

Those are systems questions, not just model questions.

The interface matters

A blank chat box is flexible, but it is often a weak interface for operational work.

It asks the user to know what to ask. It hides structure inside conversation. It makes repeatability and review harder than they need to be.

Many real workflows need the opposite.

They need systems that start from artifacts, constraints, evidence, and required outputs. They need interfaces that shape messy context into work products a human can inspect.

That is the difference between AI as an answer machine and AI as workflow infrastructure.

The right interface does not remove human judgment. It gives humans better instruments.

Evaluation has to move closer to the workflow

Benchmarks are useful, but they are not the same thing as operational evaluation.

A benchmark asks whether a model can perform a task under a defined test condition. A workflow asks whether the system can help a person complete real work under real constraints.

Those are related, but not identical.

Operational evaluation has to measure things like:

• source grounding
• consistency across repeated runs
• failure visibility
• reviewer usefulness
• latency and cost under realistic usage
• behavior when context is incomplete
• handoff quality between model output and human decision

The goal is not to replace benchmarks. The goal is to connect them to the conditions under which the system will actually be used.

Infrastructure shapes behavior

The serving layer is not neutral.

Latency changes how people use a system. Cost changes which workflows are feasible. Context windows shape what can be grounded. Quantization and routing decisions affect quality. Observability determines whether failures are noticed or silently absorbed.

The model matters, but so does everything around it:

model capability
  -> serving infrastructure
  -> retrieval and tools
  -> interface
  -> evaluation
  -> human workflow
  -> operational trust

If any layer is weak, the value of the model is constrained by the system around it.

The teams that get value from AI will be the ones that build below the demo layer: model serving, telemetry, evaluation, provenance, interfaces, and recovery paths.

That is where capability becomes something an organization can use.

What operational AI should make visible

Useful AI systems should make the surrounding work visible, not hide it behind a fluent answer.

A source-backed workflow should preserve provenance, surface reviewer questions, and keep humans accountable.

A public-data workflow should make messy information easier to explore, cluster, and reason over.

An infrastructure workflow should expose serving constraints, telemetry, quality tradeoffs, and failure recovery paths.

The common thread is operational translation.

The question for any AI project should be:

What has to exist around the model before the model becomes useful?

The broader shift

As models get stronger, the bottleneck shifts.

It shifts from capability to reliability.

From demos to deployment paths.

From answers to evidence.

From prompts to interfaces.

From benchmark performance to operational trust.

The next generation of AI work will not be won by models alone. It will be won by the people and teams who can turn model capability into systems that survive contact with real constraints.

Build the layer around the model

If you are bringing AI into a real workflow, do not stop at the model choice.

Map the system around it:

• What evidence does the system need?
• How will outputs be evaluated?
• Where will uncertainty be shown?
• What can a reviewer inspect?
• How will failures be detected and recovered?
• What should be logged for audit and improvement?

The call to action is simple: treat the model as one component in an operational system. Design the workflow, evidence, evaluation, interface, and recovery paths with the same seriousness as the model itself.

That is how AI moves from impressive output to dependable work.

Can AI help government teams move through authorization and compliance workflows by grounding every recommendation in source evidence?

ATO is one instance of a broader pattern: high-trust workflows where messy evidence has to become structured reasoning before a human can make an accountable decision.

That question matters more now because software development is accelerating faster than compliance is.

Agentic coding tools are changing the rate at which software can be produced. A small team can now generate features, tests, infrastructure changes, documentation, and pull requests at a tempo that would have looked unrealistic a few years ago. The bottleneck is shifting away from writing code and toward proving that the resulting system can be trusted.

In high-trust environments, that proof burden does not disappear. It compounds.

Every system change creates questions:

• What changed?
• Which controls are affected?
• What evidence supports the claim?
• What gaps remain?
• What would a reviewer ask?
• Which risks are acceptable, and who accepted them?

Human-driven compliance workflows were already strained when software moved at human speed. They become structurally mismatched when software starts moving at agentic speed.

The issue is not that humans are unnecessary. It is that human review capacity becomes the scarce resource. If AI can generate more software, more configuration, more infrastructure, and more documentation, then organizations also need systems that can generate more traceability, more evidence mapping, more control awareness, and more reviewer-ready context.

Otherwise, the future looks like this:

1. Agentic engineering increases delivery velocity.
2. Compliance teams receive more artifacts, more diffs, and more systems to review.
3. Manual evidence collection and control mapping become the bottleneck.
4. Authorization queues get longer.
5. Teams route around the process or slow down to survive it.

Neither outcome is acceptable.

The right answer is not to remove humans from authorization decisions. The right answer is to give humans better instruments.

What ATO Copilot does

ATO Copilot is a prototype for source-backed authorization support.

The demo ingests synthetic evidence artifacts and produces structured control analysis. It focuses on a few concrete tasks:

• mapping evidence to relevant control families
• surfacing likely reviewer questions
• identifying gaps or weak claims
• recommending next actions
• keeping outputs traceable to source material

The important design choice is that the system is not a generic chatbot.

For example, if an evidence artifact claims that audit logging is enabled, a useful system should not simply repeat that claim. It should map the claim to the relevant control area, quote the exact source text, identify whether retention or access review evidence is missing, and suggest what a reviewer should inspect next.

A blank chat interface asks the user to know what to ask. A compliance workflow needs the opposite: it should shape messy evidence into reviewer-ready work products. The interaction should start with artifacts and produce structured analysis, not start with a prompt box and hope the user interrogates the system correctly.

That is the difference between AI as an answer machine and AI as workflow infrastructure.

ATO Copilot demo interface using synthetic evidence. The screenshot shows source-backed control analysis, reviewer questions, recommended actions, and provenance traces.

Why this matters

Authorization, compliance, audit, procurement, grants, and program review workflows all share the same core pattern:

messy evidence → structured reasoning → accountable decision

Frontier models are good at language and synthesis, but high-trust environments need more than plausible summaries. They need systems that can explain where claims came from, what evidence supports them, what remains uncertain, and what a responsible human should inspect next.

This becomes more urgent as agentic coding changes the economics of software production.

If one engineer can produce ten times more system changes, the review surface expands. If multiple agents can modify code, infrastructure, tests, and documentation in parallel, the evidence surface expands again. The compliance function cannot scale by asking humans to read every artifact manually at the same depth and speed.

That does not mean compliance should become fully autonomous. It means compliance tooling needs to become evidence-native.

A useful system should be able to answer:

• Here is the evidence we found.
• Here is the control or requirement it appears to support.
• Here is the exact source text behind that mapping.
• Here is the part that looks weak.
• Here is the likely reviewer objection.
• Here is the next action a human should take.

This is the kind of work AI should do in government and regulated environments: compress the evidence surface, preserve traceability, and raise the quality of human judgment.

The product thesis

Most government AI demos begin as chat over documents. That can be useful, but it is not enough for high-trust workflows.

The stronger pattern is workflow-native AI:

• source-backed
• auditable
• constrained
• artifact-driven
• embedded in real approval paths
• designed around trust, not just speed

ATO Copilot is an early exploration of that pattern.

The prototype does not claim to automate authorization decisions. It does not contain CUI, customer data, or official assessment output. All demo evidence is synthetic.

The goal is narrower and more useful: show how AI can turn evidence artifacts into traceable control analysis and reviewer-ready next steps.

The broader shift

As software becomes more agentic, governance has to become more computational.

Not bureaucratic. Not performative. Computational.

That means policies, controls, evidence, approvals, and risks need to be represented in ways machines can help reason over while humans remain accountable for judgment.

The teams that figure this out will move faster without lowering trust. The teams that do not will face a growing mismatch between how quickly systems can be built and how slowly they can be approved.

That is the gap ATO Copilot is pointed at.

The prototype is public here: https://github.com/EthanHNguyen/ato-copilot

It uses synthetic evidence only and is intended as a product/architecture sketch, not an operational authorization system.

It is not just model research. It is not just app development. It is not just infrastructure.

The hard work sits between those layers.

The model may be capable. The product may have a real user need. The infrastructure may run. The interface may be polished. But if those pieces are designed separately, the system can still fail when it reaches a real workflow.

Frontier AI engineering is the discipline of connecting them.

The work is cross-layer

Many AI projects break because each layer makes locally reasonable decisions that do not compose.

A model team optimizes capability. An infrastructure team optimizes latency and cost. A product team optimizes the user flow. A security team limits exposure. An evaluator measures task performance. Each one may be right in isolation.

The system only works when someone can reason across the whole stack:

• model behavior and failure modes
• retrieval, context, and data quality
• serving constraints, latency, and cost
• evaluation tied to workflow outcomes
• interface design that exposes uncertainty
• security, privacy, and governance boundaries
• human review, override, and recovery paths

That is the engineering gap frontier AI exposes.

Product judgment matters more, not less

As models get stronger, it is tempting to treat product design as a thin wrapper around intelligence.

That is backwards.

Stronger models make product judgment more important because the system can now do more consequential work. The product has to decide what the model should do, what it should not do, what evidence it should show, and where human judgment should remain in control.

A generic chat interface can demonstrate capability. It rarely defines a dependable workflow.

Real-world AI products need sharper answers:

• What is the user’s actual decision or work product?
• What context is required before the model acts?
• Which outputs need citations, confidence signals, or review states?
• What failure should be obvious instead of hidden?
• Where should the system ask for human input instead of guessing?

These are product questions, but they are inseparable from engineering.

Infrastructure changes the product

The serving layer is not invisible plumbing.

Latency changes interaction design. Cost changes what can run continuously. Context limits change what can be grounded. Model routing changes quality. Logging changes evaluation. Security controls change what data can be used.

Every infrastructure decision becomes a product decision once users depend on the system.

That is why frontier AI engineering requires fluency in both directions. Engineers need to understand how infrastructure constraints shape user experience. Product teams need to understand how model and platform constraints shape what can be promised.

Evaluation has to become operational

Offline benchmarks are useful, but they are not enough to run a real AI workflow.

Evaluation is the discipline that turns model behavior from something observed into something managed. It is also one of the foundations of trust. Without evaluation, teams are left guessing whether a system is improving, regressing, or quietly failing in the parts of the workflow that matter most.

Operational evaluation asks a different set of questions:

• Did the system preserve the evidence a reviewer needs?
• Did it fail loudly when context was missing?
• Did repeated runs produce stable enough outputs?
• Did the interface help the user decide what to trust?
• Did reviewers know when to rely on the system and when to challenge it?
• Did latency, cost, or routing change behavior in production?
• Did the handoff from model output to human action actually work?

This is where model evaluation becomes systems evaluation.

Build for the handoff from model to workflow

The frontier is no longer only the model. It is the handoff from model capability to real work.

Teams applying frontier AI should build the discipline to ask cross-layer questions early:

• What does the user need to decide or produce?
• What model behavior is reliable enough for that workflow?
• What evidence, context, and provenance must be preserved?
• What infrastructure constraints will shape the experience?
• What evaluation loop will catch real failures?
• What should humans inspect, override, or audit?
• What recovery path exists when the system is wrong?

Build AI teams and systems that can reason across the full stack. The advantage will belong to the people who can translate frontier capability into workflows that survive production constraints, human judgment, evaluation, and organizational trust.

Where can I learn the most about turning frontier AI capability into systems people can actually use?

There are many good reasons to work at a large technology company. Scale, brand, compensation, and access all matter. But those were not the main reasons for me.

The main reason was proximity to the full system.

The full stack of AI value

A model is not a product by itself.

A benchmark score is not a workflow.

A demo is not an operational system.

The interesting work happens in the translation layer between model capability and real-world value. That layer includes:

• infrastructure that can serve advanced models reliably
• evaluation systems that reveal behavior benchmarks miss
• interfaces that help people use AI without hiding uncertainty
• data and retrieval systems that ground outputs in real context
• reliability mechanisms that make failure visible and recoverable
• trust layers that let organizations adopt AI responsibly

That is the layer I wanted to understand more deeply.

Google is one of the few places where the whole stack exists at serious scale: research, models, infrastructure, products, cloud, security, developer platforms, and users with real operational constraints.

That matters because the bottleneck in AI is shifting.

It is no longer enough to ask whether a model is powerful. The better question is whether that capability can survive contact with production systems, organizational workflows, latency budgets, security requirements, and human judgment.

Why scale matters

Scale is easy to talk about and hard to internalize.

At small scale, many problems look like product problems. At large scale, they become systems problems.

Reliability becomes a design constraint. Evaluation becomes continuous. Interfaces need to preserve context. Infrastructure choices show up as user experience. Small failure modes compound across millions or billions of interactions.

That is why I was drawn to Google.

The company operates at a level where AI is not just an experiment. It has to become infrastructure.

This does not make every problem glamorous. In fact, some of the most important work is not glamorous at all. It is debugging, hardening, measuring, simplifying, integrating, and making systems legible enough for people to trust.

But that is precisely the work I wanted to get closer to.

The kind of engineer I want to become

I do not want to be an engineer who only understands models in isolation.

I also do not want to be an engineer who only knows how to wrap a model in an application.

The goal is to become the kind of builder who can bridge model capability, deployment reality, and product judgment.

That means learning how frontier AI systems behave under real constraints:

• What breaks when a model leaves a benchmark?
• What does reliability mean when outputs are probabilistic?
• How should humans stay in the loop without becoming bottlenecks?
• What should be measured before a system is trusted?
• What interfaces make uncertainty visible instead of burying it?

These are not abstract questions. They show up in real systems, with real users, and real consequences.

Why Google, specifically

Google sits at a rare intersection:

• deep AI research
• world-class infrastructure
• massive production systems
• cloud and enterprise deployment
• security and reliability culture
• products used by real people every day

That intersection is valuable because it forces a builder to think across layers.

It is not enough to care about capability. You have to care about the path from capability to usefulness.

It is not enough to care about shipping. You have to care about what happens after the system meets reality.

It is not enough to care about scale. You have to care about whether the system remains understandable, reliable, and trusted as it scales.

That is the environment I wanted to learn from.

The broader thesis

The next phase of AI will not be defined only by who has the strongest model.

It will be defined by who can turn model capability into systems people can depend on.

That requires infrastructure, evaluation, reliability, interfaces, and trust.

That is why Google made sense to me.

Not because it is a destination, but because it is one of the best places to study the problem I care about most:

How do frontier AI systems become useful in the real world?

All models are wrong, but some are useful. [1]

I heard this quote today during a wonderful workshop on CyberSecurity Essentials by one of my colleagues. This aphorism succintly describes how I think about my own knowledge. What I know is a model of the world. Be humble. Assume knowledge is wrong but useful. Seek to learn everyday.

[1] https://en.wikipedia.org/wiki/All_models_are_wrong

He encourages his kids to master 3 skills:

1. Communication
2. Time management
3. Networking

As I continue in my career, I agree more with his advice.

A fellow engineer at Capital One recommended I read “The Anatomy of the Swipe: Making Money Move” by Ahmed Siddiqui to better understand the payments industry. Here, I’ll summarize my key learnings and reflect on what it means for technologists in finance.

Overview

There are four parts required to facilitate a card payment:

• A card (physical, virtual, token)
• Merchant
• Payment Network
• Secure internet connection to transmit messages.

When a customer goes to pay at a merchant, a request to approve the transaction is sent in this basic (but not exhaustive) flow: Merchant -> Merchant Acquirer -> Acquirer Processor -> Card Network -> Issuer Processor -> Issuer.

Definition of Key Players:

• Merchant - business selling the good or service. If they’re physical, they need a machine to read the card. If they’re virtual, they need a payment gateway. Examples of Merchants: Walmart, Costco, and Amazon.
• Merchant Acquirer - Partners with Merchants and provides them the tools and facilities to accept and process card-based payments. Examples of Merchant Acquirer: Chase Paymentech and Global Payments.
• Acquirer Processor - Merchant acquirer’s technology partner to connect with payment network. Usually, acquirer processor will have the hardware to connect to the payment network to request approval of transaction. Examples of Acquirer Processors: Redsys, Monext, Elavon
  • Some merchant aquirers have built this in-house or may rely on a third-party.
• Payment Network (aka Card Scheme) - Provide infrastructure for card-based transactions. Sit between Acquirers and Issuers and pass messages back and forth to enable transaction. Payment networks also set the communication rules and standards. Example of Payment Network: Visa, Mastercard, American Express, Discover
• Issuer Processor - Issuer’s technology parter to connect to the payment networks. This technology provider will usually have hardware in their data center and a fast network connection to the payment network to approve or decline transactions. Example of Issuer Processors: TSYS, Galileo, i2c.
  • Some Issuer’s have built this in-house or may rely on a third-party.
  • Note: Capital One has partnered with TSYS to help process their credit cards.
• Issuer - an Issuer or Issuing Bank’s purpose is to underwrite the user by granting them access to a bank account and potentially access to credit facilities. Ex: JPMorgan Chase, Capital One, Citi, and Wells Fargo.

The issuer will then decide to whether to approve or deny the transaction. If approved, the issuer will place a hold on the funds. Later, at the end of the day, Merchant will confirm transactions and include tips, transaction reversals, and refunds. Finally, money is moved between customer and merchant (clearing).

Payment Ecosystem

There are two types of card networks:

• Open Networks (Visa, Mastercard) - There are multiple Merchant Acquirers and Issuers. Card network makes money through fees.
  • Pros: Good for distribution. Get brand into as many consumers and merchants as possible.
  • Cons: Complex to coordinate players.
• Closed Networks (American Express, Discover) - Take their own interchange, Acquirer, and Network Assesment fees. Can adjust fee based on Merchant size. Visa accounts for ~50% of all purchase volume. American Express accounts for 13% and Discover for 2%.
  • Pros: Revenue per swipe is higher.
  • Cons: Total swipe volume is lower since the network is not as large.
• For debit cards, each Card Network has a secondary network brand for Pin Debit or Automated Teller Machine (ATM).
  • PIN Debit Network. Visa - Interlink, Visa-Net Debit. Mastercard - Maestro. Discover - Pulse
  • Durbin Amendment - every debit card must have a secondary unaffiliated network.
• ATM Networks. ATM charges user a fee. Issuer of card is charged an Interchange fee by the ATM.
  • ATM Networks - Visa - Plus. Mastercard - Cirrus. Discover - Pulse.
  • “Free” ATM networks - MoneyPass and Allpoint. Only charges the issuing bank. No cost directly charged to customer.

Flow of Payments within the Payment Ecosystem

Note: “Rewards” was added by me. What I find fascinating about this diagram is that every player in the ecosystem is incentivized to participate (i.e. every player has a “+”). I wonder - what are the costs of such a payment ecosystem?

Authorizations

• Authorization - happens at moment of swipe, dip, or tap at payment terminal. Action places hold of funds on the cardholder’s account or may decline transaction.
• Credit cards are often Dual-message Signature transaction - Authorization (message one) happens at the time of swipe. Followed up by Clearing (message two) happens in bulk at end of the night. Sometimes, Clearing message is different from Authorization if tip is included.

Clearing

• Clearing - The term “Clearing” used primarily by Issuers. Also called “Capture” by Merchant Acquirers. Clearing happens at the end of the day. Merchant will include tips, transaction reversals, and returns. Merchant confirms transactions are valid and funds are ready to be settled.
• Settlement - actual movement of money from cardholder’s bank account (Issuing Bank) to the Merchant’s bank account (Acquiring Bank). Typically happens via Fedwire.
• Card Network does not send the full amount. Card Network will
  • keep a percentage for itself as the Network Assessment Fee
  • take a percentage and pass it on to the card Issuer as the Interchange Fee
• Merchant Acquirer charges merchant an Acquirer fee too. This is charged at the end of the month.

Chargeback

• Chargeback - when a cardholder doesn’t recognize a charge on a card, they may request their money back through the Issuing Bank. Chargebacks may used when goods and services have not been provided by the Merchant, but the Merchant refuses a refund.
  • Chargeback cost merchants $25-35 per transaction. Often, merchants will eat the cost of low-value transactions.
• Merchants are encouraged to keep their chargeback rate below 1%. Otherwise, Card Network may remove the merchant.

To help fight fraud and reduce the number of chargebacks, there are a number of technologies in play:

• EMV Chip Card - Originally stood for “Europay, Mastercard, Visa” which established the technical standard of encoding card data onto a secure chip on a card. These cards are “dipped” into card terminals. Secured far more secure then data stored on a magnetic strip.
  • Merchants that have implemented this standard are not liable for fraud. The issuing bank must eat the cost of fraud here.
• 3D Secure - Standard for offering cardholders more security in online transactions. Involves the use of a one-time PIN or passcode.

Banks

• Banks have 3 purposes - Issue cards. Serve as Acquiring Banks to merchants. Facilitate movement of real money.
  • Only banks can issue credit cards. If you would like to issue a card and you are not a bank, then you must partner with a bank.
• New challenger banks are disrupting the field. They partner with small banks not subject to Durbin Amendment and its limits on interchange. Neo-banks make money off deposits and debit card interchange.
  • Note: Mobile has enabled these neo-banks to proliferate. Many consumers no longer care about the proximity of a physical bank branch when they can access the bank’s app in their pocket. Neobanks compete with traditional banks with various features such as 2-day early payday, better underwriting models for underbanked groups (ex: Karat credit card for content creators), and interest-free secured credit cards.

Taking Payments

• Independent Sales Organization (ISO) - ISO is granted a license to sell Merchant acquiring services from a Merchant Acquirer
• Payment Facilitator (PF or PayFac) - Layer on top of a Merchant Acquirer. Payment facilitators can onboard very quickly and offer out-of-the-box hardware and software to enable a merchant to take payment.
  • Advantages: Fast setup. Fixed pricing. Managed Fraud.
  • Drawback: Being a sub-merchant. Fixed pricing can be expensive.
• How do payment facilitators make money? Revenue from Software or Hardware. Revenue from each transaction. Pay Merchant Acquirer the Acquirer fee. Pay card Issuer’s interchange. Pay Network network assessment fees. PF can aggregate transactions and negotiate low Acquirer fees.
• Using a Merchant Acquirer
  • Advantages: Being a Direct Merchant. Hardware and Software options. Interchange Plus Pricing. Can use flat fee or Interchange Plus. Faster Funds settlement.
  • Disadvantages: More paperwork. Mange fraud directly.
• How do Merchant Acquirers make money? Revenue from Hardware. Revenue from each transaction.
• Payment Service Provider - Aggregator of payment methods. Allows website to get paid via debit card, mobile wallets, and financing schemes such as Buy Now, Pay Later.

Making Payments

• Co-Brand Partner - typically a brand or company marketing the card.
• Program Manager - manages the day-to-day operations of the card program including settlement, fraud management, and maintaining the relationship of the Issuing Bank, card manufacturer, card network, and cardholder.
  • Makes money by getting portion of interchange
• Issuer Processor - connection between card and network. Needs to parse an ISO8583 message (standard card transmission) and respond in 3 seconds. Licenses a piece of hardware from the Network commonly referred to as a Mastercard Interface Processor (MIP) for Mastercard and a VisaNet Integrated Processing (VIP) for Visa.
  • Also responsible for integration with co-brand. May provide alerts or ability to turn on/off card. Issuer Processors provides APIs and documentation.
  • Makes money as a utility based on number of cards or on each transaction.
• JIT Funding - Forward details from card swipe for approval.
• Issuing Bank - works with Program manager to provide the settlement and bank accounts
  • Makes money by possibly charging Program Manager fees for setting up bank accounts, performing compliance audits, and general oversight. Issuing Bank also sponsors BIN. Card networks only give BIN to banks.

Know Your Customer (KYC)

• KYC - Practice in banking or finance used to attach identity to a user of a product
• For a better user experience, you should progressively ask for more and more information from the customer on a need-to-know basis. This step is critical especially for underbanked customers.

Credit vs Debit Card

• 23% of millennials don’t carry credit cards (TD Bank’s Annual Consumer Spending Survey)
  • Prefer credit cards for simplicity of seeing spending balance
  • Note: I believe there’s an opportunity here to help millenials / generation Z better to better understand and feel secure with their money. The increased costs of higher education (and their associated student loans), increased cost of living, and skepticism towards social safety nets such as Social Security are contributing factors to feeling anxious about one’s personal finance.
• Some industries such as travel prefer credit cards because funds are guaranteed by the Issuing Bank

Interchange

• Durbin Amendment - Banks with assets greater than \$10 billion are regulated for Interchange fees. Regulated Issuers get \$0.21 + 0.05% of the transaction amount + \$0.01 for fraud.
• Merchants who clear faster qualify for lower Interchange rates.
• Track 3 data - Some merchants provide receipt level details (Track 3 Data) to card networks. When this data is provided, lower interchange is charged.

Other solutions for merchants to lower interchange fees:

• Private label cards - Some merchants offer their own cards to use at the store. These cards only work at the store that issued the card. Benefits include direct access to customer spending data, reserves spot in customer wallet, no interchange paid to issuer, little or no fees paid to acquirer, brand loyalty.
• Co-Brand Cards - Brand partners with an issuing bank and card network. For example, Amazon partnered with Chase and Visa to create an Amazon credit card. Since Amazon arranges this deal, they will typically get lower network assessment fees with the network and lower interchange with the issuing bank. The brand and issuing bank can also earn interchange on transactions outside of brand.

Moving Money without Card Networks

• ACH
  • Over 82% of electronic payments in the US are ACH (Automated Clearing House)
  • ACH is a technology offered by the “Clearing House,” which is a nonprofit organization. This is a network of banks that have come together to enable movement of money interbank through the use of bank account and routing number. This is a batch process.
  • Efficient and inexpensive. However, it’s not the fastest. Since it’s a batch process, there are “cutoff windows”
  • Direct Deposit - type of ACH transfer that typically comes from an employer into an employee’s bank account. Employers would give Fed NACHA file to transfer the funds. This NACHA file is often sent earlier but funds are only moved on effective date. However, some banks are willing to loan money for 2 days once they see the NACHA file from the employer.
  • NACHA is pushing for faster payments by offering Same-Day ACH
• Peer-to-Peer and ACH
  • Venmo - Venmo, using Plaid, can see the state of the bank account. Venmo can safely float the funds for a couple days as it waits for ACH However, to the sendee, the funds are sent immediately.
  • Zelle - Groups of banks share a ledger. Money moves quickly and does not wait for “settlement”.
• Wire Transfer
  • Way to move money (usually large dollar amounts) from one bank to another securely and quickly by using account and routing numbers of the sending and recieving banks.
  • In the US, the Federal Reserve provides Fedwire which is the primary way to wire funds between banks. This is the supported by almost every bank. The Clearing House also provides a wire service called Clearing House Interbank Payments System (CHIPS).
  • Movement of money is instant. However, humans need to confirm that money has moved.
• Real-time Payments
  • Wire transfers are used for large transfer, but can also be applied to smaller payments. Main barrier is that cost of wire is high because humans need to confirm money movement.
  • Real-Time Payments (RTP) - way to push money within seconds by sending money directly to a bank account offered by The Clearing House.
  • Cost is capped to $0.045 per transfer

How do you create a credit card?

As an engineer working within the Card division at Capital One, I have thorougly enjoyed learning about the various parts of the payment ecosystem. I don’t know a lot about payements yet, but I am learning more everyday.

One observation that I’ve had is that most of the innovation happens on either end of the swipe — closest to the merchant or customer. The underlying core infrastructure often remains stagnant on old technology (however, this is changing too. re: peer-to-peer payments, decentralized ledgers, blockchain). At Capital One, the company is focused on the customer side of payments. One driving question I’ve been asking myself is, “What valuable niches exist in the market and how can Capital One design a credit card for that niche?”

There are many ways to spot niches in the market. You can divide the market up into new to credit, mainstreet, premium, and ultra-premium. You can look at consumer vs. business cardholders. Or, you can also look at the payment market from the merchant side too and examine co-brand opportunities.

Once you have identified the niche, you need to create a monetized product to cater to those consumers. At Capital One, there are two main sources for revenue in credit cards: credit card interest (16.6 billion USD in 2022) and interchange fees (4.6 billion USD in 2022) [2]. The credit card must offer the consumers compelling benefits in order to 1) use the credit card (interchange fees) and 2) revolve and eventually pay off a credit card balance (net interest income).

Now, you need to create the credit card. This involves designing the credit card benefits, advertising the card, handling customer applications, underwriting each application, obtaining capital to loan, and servicing the card. Fortunately, Capital One (and other credit card companies) are platform companies and they have already built a lot of the tools in-house. They benefit from economies of scale. They have low-cost to access capital through their own customer deposits. They have advertising partnerships with top athletes. They have pre-existing web, mobile, and physical channels for applying and servicing a card. Lastly, they are a brand to whom you would search for other financial products such as another credit card, a high-yield checking/savings account, or a car loan.

Similar to how AWS has become the platform to power the web, Capital One needs to become the platform for consumer financial products. As software engineers, software will play a critical role in 1) automate processes such as application, issuing virutal cards, underwriting each application, analyzing fraud risk, and marketing new cards and 2) analyzing large amounts of data to better underwrite and create additional financial products.

Sources:

[1] The Federal Reserve Payments Study: 2022 Triennial Initial Data Release. https://www.federalreserve.gov/paymentsystems/fr-payments-study.htm

[2] 2022 Capital One Annual Report. https://www.capitalone.com/investor/financials/annual-report/

Vector databases are databases that store vectors. Their core function is semantic search — if you have an input vector, you can find the top k most similar vectors in the database.

Why Vector Databases?

Large language models (LLMs) are a type of generative AI that generates text. LLMs are trained on vast amounts of text data, but they have two limitations:

1. LLMs are trained on a lot of data, and compress that vast training data into their limited memory. They lose some information in this compression.
2. LLMs do not have access to proprietary information. LLMs are only trained a publicly available data.

To fix these two issues, one popular approach has been to feed information the LLM needs into its context [1]. LLMs have “good” reasoning ability [2], and will use this context to craft a more helpful and specefic response. Vector databases are used to store this context information.

How can they be used in business to automate process X?

Vector databases are used to give more information to LLMs outside their training data. For business, this often includes their own proprietary data. Let’s walk through a use case.

Assume a business conduct sales through email. They hire salespersons with varying levels of abilities. The best salesperson can sell 40% more products than the average employee. As an ML engineer, we can design a system to help the average salesperson obtain the sales figure of the best salesperson. Here’s how:

The business has all the data on a customer email and how their best salesperson responds. These pairs of emails are examples that we can use. We insert these email pairs into a vector database. Now, when the business receives an email from the customer, the system can find similar email examples in the vector database, pass it into the LLM’s context as examples, and ask the LLM to generate a new email to respond to the customer using these examples.

Using this system, every salesperson in the company can be brought up to the level of the best salesperson.

Where can I learn more?

I find LLMs and vector databases are fascinating too! There are many resources to learn more about them. Here are a few:

If you want to understand the landscape of vector databases and their technical details, checkout The Data Quarry’s series of blogs: https://thedataquarry.com/posts/vector-db-1/

If you’re interested in seeing a tutorial for this use case, the YouTube channel AI Jason has an excellent video for this: https://www.youtube.com/watch?v=c_nCjlSB1Zk

Conclusion

Vector databases are used to store additional contextual information for an LLM. This can include information more specific to the problem such as sales data. It is important to note that vector databases are used for more than just LLMs.

LLMs have potential to not only automate processes but also close the skill gap between senior and junior employees. They can also help retain proprietary knowledge when senior employees leave. In business, ML systems can help automate processes and improve the productivity of their employees.

Notes:

[1] The other common approach is fine-tuning.

[2] LLMs are known to make reasoning mistakes. It is still unclear whether current LLMs are capable of true reasoning. However, this will likely improve over time with more data and better models. Check out these research articles: https://arxiv.org/pdf/2212.10403.pdf and https://arxiv.org/pdf/2303.12712.pdf.