Google CloudProfessional Agentic Architect2026-092.2 Customizing coding agents for enterprise workflows
Choose the right coding-agent customization
Completed by the knowledge check
Learning objective
Choose among rules, skills and plugins, hooks, and subagents according to their architectural roles. This lesson does not cover detailed hook configuration or subagent privilege design.
Core idea
Use four questions to classify a coding-agent customization:
- Policy: What behavior should guide the agent? Use a rule.
- Capability: What repeatable task should the agent know how to perform? Use a skill, and use a plugin when you need to package and distribute a set of customizations.
- Interception: What code must run at a specific execution boundary? Use a hook.
- Delegation: What work should run in a separate agent session? Use a subagent.
These mechanisms can work together, but they are not interchangeable. Remember them as policy, capability, interception, delegation.
How it works
Rules express policy
A rule is an instruction or constraint that guides the model’s behavior. A workspace rule might require tests or specify repository naming conventions. Antigravity rules can be global or workspace-specific and can activate manually, always, by model decision, or for matching file globs (Rules).
A rule influences reasoning and generated actions. It is not, by itself, a hard execution barrier. Use a rule for standards and preferences that require contextual judgment. If violating a condition must mechanically stop an operation, enforce that condition with a deterministic control such as a hook, permission boundary, or external policy system.
Skills add reusable capability
A skill gives the agent task-specific knowledge and a method to follow. An Antigravity skill is a directory with a required SKILL.md and optional scripts, examples, and resources. The agent first receives skill names and descriptions, then loads the full instructions when a skill is relevant. This progressive disclosure adds specialized capability without putting every procedure into every prompt (Agent Skills).
Use a skill for work such as applying a database migration procedure. A skill may tell the agent which checks to run, but those instructions do not make the checks deterministic.
A plugin is a packaging and distribution boundary, not a fifth runtime behavior. In Antigravity, a plugin can group skills, rules, Model Context Protocol (MCP) server definitions, and hooks in one namespaced package (Plugins). Use a plugin when a team must install, version, or share related customizations together. After installation, each included component still performs its own role.
Hooks intercept lifecycle events
A hook runs a script or command at a defined point in the agent loop. Supported events include before and after a tool call, before and after a model invocation, and when the loop stops. A PreToolUse hook receives the proposed tool call and can return a decision such as allow, deny, ask, or force_ask (Hooks).
Use a hook when timing and repeatability matter: block a forbidden command before execution, record tool results after execution, or require a final verification before the loop stops. The trigger is deterministic, but the hook is only as correct and available as its script. A post-action hook also cannot prevent the action that already occurred.
Subagents delegate work
A subagent is a separate agent session created for a bounded task. In Antigravity, the parent invokes a subagent with a role and initial prompt. The subagent has its own context rather than inheriting the parent’s conversation history, and multiple subagents can run concurrently (Subagents).
Use a subagent when specialization, parallelism, or context isolation is worth the coordination cost. A subagent does not automatically add a capability, enforce a rule, or improve correctness. The parent must provide a clear task, sufficient context, suitable tools, and a way to verify the result.
Key distinctions and trade-offs
The following table maps each design need to its primary mechanism:
| Need | Mechanism | Main trade-off |
|---|---|---|
| Guide decisions and output across relevant work | Rule | Low setup cost, but model compliance is not hard enforcement |
| Teach a repeatable, specialized procedure | Skill | Reuse and focused context, but activation and execution remain agent-directed |
| Distribute related customizations as one unit | Plugin | Easier sharing and versioning, but included components can have different runtime roles |
| Run logic at a precise execution boundary | Hook | Deterministic timing, but adds code, latency, and failure modes |
| Move bounded work into another context | Subagent | Parallelism and specialization, but adds coordination, cost, and result-integration work |
Start with the problem. A hook is unnecessary machinery for explaining a coding style; a rule is too weak for blocking a dangerous tool call. A subagent adds handoff overhead when one agent could follow a skill instead.
Architecture / decision scenario
A platform team wants coding agents to prepare Terraform changes for several service repositories. The architecture uses each mechanism for a different reason:
- A workspace rule tells agents to use the team’s module conventions and to explain every production-impacting change.
- A Terraform-review skill supplies the review sequence, approved templates, and helper scripts. The team distributes it with related customizations in a versioned plugin.
- A
PreToolUsehook inspects proposed command executions and denies a production apply that lacks the required prior grant. This control runs at the boundary before the command executes. - A read-focused subagent examines the existing infrastructure and returns a risk summary while the parent prepares the plan.
The rule shapes judgment, the skill provides know-how, the plugin carries the customizations, the hook gates an action, and the subagent performs delegated work. Replacing the hook with “never apply without approval” in a rule would turn a required control into probabilistic model behavior. Replacing the skill with a subagent would create another worker without giving it the team’s procedure.
Common exam traps
- Treating a rule as guaranteed enforcement because it uses strong words such as “must” or “never.”
- Treating a plugin as another name for a skill. A skill provides task guidance; a plugin packages one or more customization components.
- Choosing a hook to teach a procedure instead of to intercept a lifecycle event.
- Choosing a subagent merely because a task needs a new tool or reference. That is a capability need unless separate execution adds value.
- Assuming a separate subagent context guarantees least privilege or an independent result. Tool scope and verification still require deliberate design.
- Assuming more mechanisms always produce a better system. Each mechanism adds maintenance, context, runtime, or coordination cost.
What to remember
- Rules guide behavior; they do not create a hard execution boundary.
- Skills teach reusable procedures, while plugins package customizations for distribution.
- Hooks run code at defined lifecycle points and can gate actions before they occur.
- Subagents move bounded work into separate agent contexts.
- Select and combine mechanisms by their architectural role: policy, capability, interception, and delegation.
Knowledge check
A team wants to distribute related skills, rules, MCP configuration, and hooks as one versioned installation. Which mechanism owns that packaging role?
A team needs a mandatory argument check before a shell command runs. Which customization owns that execution timing?
A bounded repository investigation should run in parallel with the parent’s work and return a cited report from its own context. Which mechanism provides that execution separation?
References
- Google Antigravity, Rules
- Google Antigravity, Agent Skills
- Google Antigravity, Plugins
- Google Antigravity, Hooks
- Google Antigravity, Subagents