Staff / Principal Engineer

Working with agents

Staff and principal engineers help teams make technical decisions that affect more than one task or service. Agent-assisted work adds questions about context, tool access, review and interactions across the system.

For a product that runs agents, this may include model selection, data flow and recovery. For a team using coding agents, start with the development workflow and the system boundaries their changes must respect.

The AI Architect name describes a set of responsibilities in HELM. Agree how your team covers them rather than assuming a new title is needed.

Experience to discuss

Discuss architecture, technical leadership and mentoring through concrete decisions. What alternatives did the person consider, who did they involve, and how did they check the result? Use agent-related scenarios where they match the work.

Responsibilities and skills

Purpose

Make architecture, data-flow and operating decisions clear enough for people to implement and review, including when agents do part of the work.

Responsibilities to discuss

• Select models and assign responsibility by task class, weighing capability, cost, latency, and failure sensitivity
• Design end-to-end data flow from inputs through processing, persistence, and outputs—including what agents may read, write, or infer
• Choose orchestration patterns (single agent, multi-agent, deterministic workflow, or hybrid) based on task structure, reversibility, and oversight requirements
• Define failure modes, recovery paths, and escalation triggers before agents encounter them in production
• Define architectural constraints and check that agent changes respect them
• Review system-design decisions across teams for compatibility and maintainability
• Own the evaluation architecture: what can be measured, how evaluation data flows through the system, and how system-level health is assessed
• Record decisions, alternatives and constraints so later work can build on them

Skills for this work

These role-specific skills complement the five shared competencies. Choose examples relevant to the work and support people as they practice.

• System design mastery — Design the interfaces, data flow and operating limits for systems that include agents.
• Orchestration pattern expertise — Choose a workflow or agent pattern that fits the task, and explain why simpler options are insufficient.
• Failure mode thinking — Plan for incorrect outputs, repeated actions, stale instructions and unclear ownership, including how to detect and recover from failures.
• Cost-performance reasoning — Compare model and routing choices using task quality, response time and cost.
• Technical communication — Explain architecture decisions through clear task boundaries, diagrams and instructions.
• Cross-domain judgment — Assess output quality and design risk across domains (backend, data, security, UX) when agents span them.

Signals that need more context

Use work examples alongside these signals; none is a complete measure of someone’s ability.

• Code volume without evidence of the decisions and results behind it
• Language or framework expertise without examples of wider system judgment
• Expectation that you personally implement every subsystem you design
• Individual achievements without evidence of collaboration or knowledge sharing
• LeetCode-style algorithm screens disconnected from system and agentic design

Questions to discuss

Adapt these example questions to the role and the person’s opportunities to do the work.

• System design — Design an agentic system for a realistic product scenario—model selection, orchestration, data flow, and failure handling.
• Architecture review — Critique an existing agent architecture for failure modes, cost risks, scalability limits, and boundary violations.
• Decision-making — Given a working agent-generated solution that introduces structural risk, decide what to ship, what to block, and what to change.
• Trade-off analysis — Compare two orchestration approaches for the same problem; defend a recommendation with explicit trade-offs.
• Guardrail design — Specify scope, quality, and policy guardrails for a concrete agent workflow, including escalation.

An example day

Illustrative scenario. Use this example to discuss how the responsibilities fit together.

You compare a fixed workflow with an agent loop for a new feature. The team reviews the expected quality, cost and failure cases before choosing the simpler option that meets the need.

Later, an implementation review reveals that customer data crosses a service boundary it should not cross. You agree a correction and record the decision so future tasks include the same constraint.

Related HELM guidance

The AI Architect responsibilities cover technical direction. Use the Decision Rights Matrix to agree who decides, the Guardrail Stack to review controls, and the Composition Patterns to compare implementation options.

Principle 5: Structure Over Tooling asks the team to keep responsibilities clear as its tools change.