The AI Workbench

AI changes every week. Your operating system should not. This manual is a way to make a good decision before opening a chat box: choose the job, choose the working mode, give the system a usable contract, and decide how you will know the work is right.

This is deliberately not a leaderboard. Model rankings expire quickly, and the “best” product depends on the task, the data, the deployment, and the cost of being wrong. The durable advantage is knowing how to structure work so that today’s best available model can help without becoming an unaccountable black box.

1. Begin with the job, not the logo

Before choosing a model or product, answer four questions:

1. What must exist at the end? An answer, a sourced brief, a deck, a code change, or a recurring result?
2. What evidence must support it? Primary sources, calculations, passing tests, an approved brand system, or human judgment?
3. What is the consequence of a mistake? Private rework, a confused colleague, a customer-facing error, a security incident, or money moved?
4. Will this exact shape of work recur? Once, occasionally, or on a stable schedule?

These answers select the working mode. The model comes after.

2. Use five working modes

A 30-second decision path

1. Can one response finish the work? Use Ask.
2. Does the answer depend on fresh facts or a body of sources? Use Research.
3. Does someone need to open, present, run, or edit the output? Use Create.
4. Are there multiple bounded steps or tools? Use Delegate.
5. Has the same workflow succeeded repeatedly with clear exceptions? Consider Automate.

Do not automate the first draft of a workflow. Run it manually, learn where judgment is hiding, and only then turn the stable parts into a template, skill, agent, or scheduled task.

3. Give the system a work contract

Vague prompts create plausible motion. A work contract gives the model enough context to act and gives the human a basis for review. Use six fields:

GOAL
What should exist when this is done?

CONTEXT
Who is this for? What happened before? What files or systems matter?

CONSTRAINTS
What must it preserve, avoid, or never do?

DONE
What observable conditions prove completion?

EVIDENCE
Which sources, tests, calculations, or examples must support the result?

PERMISSIONS
What may it read, change, send, publish, spend, or deploy?

For a small request, this can be six lines. For a codebase, the contract belongs in repository instructions such as AGENTS.md or CLAUDE.md, plus the issue, tests, and local documentation. For a recurring workflow, make the contract a maintained template instead of re-inventing it in each chat.

4. Choose a starting tool by task

This map is a starting point as of July 30, 2026—not a permanent endorsement. Use the approved enterprise version where company or customer data is involved. Within a product, select the strongest current model appropriate to the latency and cost of the task.

Run a bakeoff for important recurring work

Take three representative tasks—easy, typical, and adversarial—and run the same contract through two plausible tools. Score output quality, time to acceptable result, source quality, edit burden, privacy/deployment fit, and total cost. Keep the winner for that workflow, not for every workflow.

5. Work well with Codex, Claude Code, and Google Cloud

Coding agents are most useful when they can see the repository, use its tools, and verify the result. They are least useful when asked to make a sweeping change with no local rules or proof.

• Put durable instructions in the repository. Record architecture boundaries, commands, style, risky areas, and the definition of done.
• Ask for one coherent vertical slice. A small end-to-end change is easier to test and review than a broad layer-by-layer rewrite.
• Name the verification commands. Type checks, unit tests, builds, migrations, and browser checks should not be left to guesswork.
• Keep permissions narrow. Reading, editing, deploying, sending, and deleting are different capabilities. Grant only what the current step needs.
• Review the diff and the behavior. Clean-looking code can still encode the wrong assumption.
• Checkpoint long work. Preserve decisions, completed steps, known failures, and the next test so another session can resume without reconstructing history.

Codex and Claude Code are agentic coding products: they provide a harness around one or more models so the model can inspect files, use tools, edit code, and run verification. A hosted model is not the same thing as that harness.

On Google Cloud, Claude models are available through Vertex AI, and Claude Code can be configured to use Vertex AI for model access. That path is useful when an organization wants Google Cloud IAM, billing, auditability, and deployment controls. The CLI remains the working interface; Vertex AI is the managed model and governance layer underneath it.

6. Treat the harness as part of the product

Harness engineering is the design of the system around the model: instructions, context assembly, tools, permissions, state, checkpoints, tests, observability, and recovery. The model supplies capabilities. The harness makes those capabilities reliable enough for a real workflow.

A production-worthy harness has at least six parts:

1. Contract: the goal, constraints, and definition of done.
2. Context: the smallest relevant set of facts, files, examples, and prior state.
3. Capabilities: narrow tools with explicit read and write boundaries.
4. State: durable progress that survives long runs, retries, and handoffs.
5. Verification: deterministic checks where possible and calibrated human review where judgment remains.
6. Recovery: bounded retries, clear failure states, rollback, and an owner.

Agentic engineering is the broader practice of designing software and operations in which models can plan and act through tools. Our current stance:

• The model is a component, not the architecture. Keep model choice replaceable.
• Autonomy is earned. Start with supervised, reversible work and expand only from observed performance.
• Context is engineered. Retrieve and compress what matters instead of dumping everything into a prompt.
• Guardrails should be capabilities. It is safer to withhold a dangerous tool than to merely ask the model not to use it.
• Every important action should be attributable. Record inputs, tool calls, outputs, errors, approvals, and the final disposition.
• Failures become evals. A real miss is a test case for the harness, not just a prompt anecdote.

7. Match verification to consequence

Fluent output is not verified output. Increase the verification burden as the consequence of error rises.

An interim data rule

Until a portfolio company has an approved AI data policy, classify inputs as public, internal, confidential, or restricted. Public information may use approved general tools. Internal and confidential information should use the company’s approved enterprise environment and settings. Restricted information—credentials, regulated records, privileged legal material, sensitive personnel data, or customer secrets—should not enter an AI system unless the owner has explicitly approved that system and workflow.

8. Promote successful work deliberately

Most useful AI systems begin as one person doing one task well. Promote the workflow one rung at a time:

1. Good one-off result → template. Save the contract and an example.
2. Repeated template → skill. Package the instructions, inputs, outputs, and checks.
3. Several tools or stateful steps → agent. Add a harness, permissions, checkpoints, and recovery.
4. Stable trigger and known exceptions → automation. Schedule it, observe it, and give failures an owner.
5. Customer- or business-critical behavior → product system. Add an eval set, release discipline, monitoring, security review, and accountable ownership.

The aim is not maximum autonomy. The aim is the cheapest reliable system for the consequence of the work.

9. Put this into practice in 15 minutes

1. Choose one real task due this week.
2. Name its mode: Ask, Research, Create, Delegate, or Automate.
3. Write the six-line work contract.
4. Choose one starting tool from the map.
5. Run the task and apply the right verification level.
6. Record one thing the system misunderstood or could not do.
7. If the work will recur, save the contract and result as the first test case.

10. Terms worth using precisely

Model

The learned system that predicts and generates outputs. It is a component inside a product or harness.

Product

The user-facing application—such as ChatGPT, Claude, Gemini, Gamma, or Canva—that packages models with interfaces, tools, storage, and policies.

Agent

A model-driven system that can choose and execute multiple steps through tools toward a goal.

Tool

A capability the system may invoke: search, a database query, file editing, a browser, an API, or deployment.

MCP

Model Context Protocol, a standard way for AI applications to connect to tools and context providers.

Skill

A reusable package of instructions, references, and sometimes scripts for a defined kind of work.

Context engineering

Selecting, structuring, and maintaining the information a model needs at each step.

Harness engineering

Designing the instructions, tools, permissions, state, verification, observability, and recovery around a model.

Eval

A repeatable test of system behavior using representative tasks, expected properties, and a scoring method.

Agentic engineering

Building software and operations in which models can plan and act through tools under engineered constraints.

Sources and further reading

• OpenAI: Codex best practices—context, repository instructions, skills, scheduled tasks, and verification.
• Anthropic: Claude Code documentation—working with Claude Code and supported deployment paths.
• Anthropic: Claude Code on Google Vertex AI—configuration and authentication through Vertex AI.
• Google Cloud: Claude in Vertex AI Model Garden—managed access to Claude models on Google Cloud.
• Anthropic Engineering: harness design for long-running agents—state, progress, and continuity.
• Anthropic Engineering: evals for AI agents—turning expected behavior into repeatable tests.
• Gamma: AI presentations.
• Canva: Magic Studio.
• Google Workspace: create presentations with Gemini in Google Slides.

Related DVx research

• How we build software across the portfolio
• How We Rebuilt QSR Around Multi-Agent AI
• Rebuilding our Access Control for AI Agents
• The agent doesn’t hold the data. It decides where to go get it.
• We stopped treating agent latency as one number.