Defining Agentic Latitude

Agentic latitude is the degree of discretion a Product Engineer gives a coding agent to make decisions beyond the details explicitly provided. It is not a single global permission setting. Latitude can differ by decision category, work increment, and project or client.

The Product Engineer is responsible for identifying both:

1. Where latitude is welcome: areas in which the agent may propose or implement ideas without receiving detailed prescriptive instructions.
2. Where specificity is required: boundaries, requirements, or decisions that the agent must not extend, reinterpret, or change independently.

Freedom and specificity are complementary. A Product Engineer may invite substantial UX creativity while prescribing an exact functional scope and fixed page inventory. Another project may allow the agent to propose functionality but require strict adherence to a defined visual system or content policy.

These four initial categories are practical lenses, not a claim that every decision fits neatly into only one category.

A project may need additional categories such as integration or operational latitude, but these should not become mandatory new framework bureaucracy. Existing enterprise security policies and approved architecture remain binding regardless of latitude.

The Product Engineer defines both freedom and specificity for the next outcome. A client may welcome broad UX exploration while fixing page inventory and functional scope; another may invite functional suggestions while retaining exact visual and content policy. Make the boundaries as explicit as the invitation to create.

If a category is unspecified, it does not grant unrestricted permission to expand the product. Follow the current request, standing project/enterprise instructions, and reasonably implied scope. Propose material additions separately and seek direction before implementing them. Latitude never authorizes invented business policy, privileges, new dependencies or irreversible effects outside granted authority.

SHAPE recommends building and validating software in small, coherent increments, with agentic latitude defined for each increment. This is the default practitioner path, not merely one option among equal alternatives.

Start with the minimum useful foundation, implement one understandable capability, inspect the working outcome, adjust intent and latitude, and proceed to the next capability. Do not confuse small increment with a rigid requirement for tiny commits or one-screen changes. An increment should be small enough for the Product Engineer and relevant stakeholders to understand and assess its consequences.

For a website, increments might be: initial layout and navigation; visual direction; authentication; account management; then the first substantive product workflow. For an ERP extension, increments might be: integration boundary and data model; a single business operation; associated permissions and validations; then related workflows. These sequences illustrate the practice and are not universal mandatory stages.

A large initial prompt or comprehensive specification can yield an impressive prototype and may be suitable for bounded experiments. It also permits accumulated decisions the Product Engineer has not consciously made: additional pages, unrequested features, invented business rules, large volumes of content, new dependencies, or undesired organization.

The result may look polished while exceeding what the owner understands or feels comfortable publishing. The Product Engineer then shifts from proactive direction into reactive damage control, spending time discovering what exists, removing unwanted behavior, and reversing agent assumptions. Fast reversion helps, but does not eliminate the cost of understanding, reviewing, and untangling a large result.

Present this risk clearly without claiming that all broad prompts fail or that agent-created prototypes are inherently poor. The SHAPE recommendation remains incremental development even when a one-shot prototype has succeeded in other circumstances.

Use this lightweight practice during discovery, implementation, and enhancement; it is a recommended method, not a new governance stage.

Step 1: Define the next outcome

State the smallest coherent working result worth inspecting. Identify the users and the behavior that should be demonstrable when the increment is complete. Avoid specifying the entire future product when only the next increment is being built.

Example: “Implement a basic account page that allows a signed-in user to view their profile and change their password.”

Step 2: State the scope boundary

Explicitly describe what is included, what is excluded, and what must not be introduced without asking. Give special attention to unrequested pages, functionality, business rules, external integrations, or large volumes of content.

Example: “Do not add profile photos, subscriptions, additional account settings, or new navigation sections. Propose them separately if they seem useful.”

Step 3: Set latitude by category

Decide where the agent can exercise discretion. The Product Engineer need not create a formal matrix for every tiny change, but the categories should be considered and articulated when ambiguity or drift risk is meaningful.

Example: “UX: moderate latitude within the existing design system. Structure: low; keep current routes. Functionality: none beyond the described account actions. Content: low; use concise labels, no invented help pages.”

Step 4: Identify immutable or approval-controlled constraints

Confirm enterprise security controls, approved stacks, shared design assets, protected instructions, and other binding decisions. Latitude never permits the agent to bypass these. Identify any decisions that require explicit human authority, especially business policy, data deletion, permissions, or external system effects.

Step 5: Implement one coherent increment

Direct the agent to use approved assets and implement only the bounded outcome. Encourage useful suggestions without silently expanding the product: the agent may note additional opportunities for the Product Engineer to consider, separately from the implemented scope.

Step 6: Inspect the working product

Use the result. Check what was built, what the agent assumed, what was added beyond scope, and what needs correction. Review the actual pages, workflows, operations, or API behavior rather than relying solely on the agent's completion summary. The effort of review must remain manageable.

Step 7: Adjust and repeat

Revise the product directly through feedback. Change the latitude if useful for the next increment. Ensure the agent maintains the relevant intended-behavior context for future work and independent verification. Move forward when the result is acceptable for the current stage, not when an intermediate prose document has received ritual sign-off.

This is an optional prompting pattern, not a mandatory file format, new artifact or approval ceremony. Use only the detail useful to the increment; boundaries can be spoken, typed, or kept in appropriate project context.

## Next increment
[What working result should exist after this change?]

## Scope
Include: [required behavior and content]
Exclude: [features, pages, workflows, or content that must not be added]

## Agentic latitude
- Creative / UX: [how much discretion and within which constraints]
- Structural: [what organization can change]
- Functional: [whether additional behavior may be proposed or implemented]
- Content: [what may be drafted or invented]

## Decisions requiring approval
[Business rules, new dependencies, major scope expansion, or other decisions the agent must escalate]

## Review target
[What the Product Engineer will run, inspect, or demonstrate]

Leaving a category unspecified is not permission for unlimited expansion. Useful suggestions can be presented separately from what is implemented.

These scenarios are illustrative and hypothetical, not real client implementations.

5.1 Documentation website: broad UX latitude, narrow scope and content

Intent: Build the first version of a framework website using the sections the owner has explicitly authorized.

• Creative / UX: Broad freedom to present the approved material clearly and professionally within the design system.
• Structural: Freedom to organize content within approved pages; no additional top-level pages or new content sections without approval.
• Functional: Only the specified website functionality; propose extra utilities instead of silently implementing them.
• Content: Use provided framework decisions and source materials; do not invent case studies, additional methodologies, or publishable claims as though they were approved.
• Increment: Start with navigation, homepage, and one representative substantive page. Inspect before populating the rest.

Why this matters: A single giant website specification may encourage the agent to generate dozens of plausible pages and case studies. Their quality can be high while the owner remains unfamiliar with what the site now publicly says.

5.2 ERP workflow: limited functional latitude, focused implementation

Intent: Add one new approval operation to an existing enterprise system.

• Creative / UX: Some latitude to reuse existing screen patterns and improve clarity.
• Structural: Respect current module boundaries and approved extensions.
• Functional: Narrow; do not introduce new workflow states, accounting effects, permissions, or integrations without approval.
• Content: Use established domain terminology and policies.
• Increment: Deliver one end-to-end operation with authorization and validation, then expand to related workflows after inspection.

Why this matters: Inventing a plausible additional workflow can create business and data consequences even when the generated UI appears useful.

5.3 Exploratory internal prototype: deliberately broad latitude

Intent: Explore alternative approaches to a bounded problem, with no production publishing or irreversible effects.

• Creative / UX: Broad.
• Structural: Broad within the prototype boundary.
• Functional: Exploratory suggestions and disposable implementations permitted.
• Content: Synthetic examples permitted if identified as such.
• Increment: Still start with a small demonstrable slice; broaden after inspecting the first result.

Why this matters: Broad latitude can be an advantage when exploration is the explicit goal and reversibility is high. It should be intentional, not the accidental result of an underspecified prompt.

Agentic drift is product expansion or redirection caused by agent decisions that fall outside the Product Engineer's intended or authorized boundaries. An unexpected idea is not drift merely because it was unexpected. It becomes a problem when its implementation exceeds the granted latitude, violates a constraint, or is introduced as an unapproved decision.

Common indicators include:

• Unrequested pages, modules, features, integrations, or complex content.
• Invented domain policies, validation rules, permissions, or acceptance criteria.
• New dependencies or patterns where approved building blocks exist.
• A growing product surface that the Product Engineer cannot reasonably inspect.
• Agent summaries that focus on how much was generated rather than what was actually validated.
• Repeated cleanup or deletion after large implementation runs.

The countermeasure is to constrain the size of the next increment, specify decision latitude, inspect the outcome, and expand deliberately.

Product Engineer: Sets outcome, scope, and latitude; identifies decisions requiring authority; inspects actual behavior; redirects work; manages the pace and reviewability of increments. The PE need not write elaborate specifications or formally sign off on each document to exercise this control.

Coding agent: Uses discretion only within the defined latitude and standing project/enterprise instructions; does not silently expand the agreed scope; raises material additions as proposals; maintains relevant intended-behavior context.

Architect / Senior Engineer: Establishes and interprets technical constraints; reviews consequential deviations and the implementation at the framework's agreed checkpoints. Defining agentic latitude does not introduce another mandatory architect approval gate.

UX Designer: Establishes UX boundaries where needed and reviews outcomes; can deliberately grant creativity within an approved system. No exhaustive upfront design requirement is introduced.

Business stakeholder: Owns consequential business rules and accepts the working product through the relevant review and UAT processes. Agentic latitude cannot transfer business accountability to an agent.

A Product Engineer may express intent conversationally and inspect functioning software without a formal human sign-off on intermediate specifications. Agentic latitude should be expressed in the work request and maintained project context. Agents can keep specifications synchronized as operational context for later implementation and independent verification; the product, not the specification document, is what humans ultimately assess and accept.

Defining boundaries is not the same as requiring a huge upfront requirements document. A short, precise statement of what the agent may decide and what it must not change is often more effective than extensive prose.