Outer Developer Loop (weeks/months)

Question 2

What is the Outer Developer Loop characterized by?

Answer 2

Moves slowly but powerfully: weeks to months, sometimes longer

It focuses on long-term changes to tools, architecture, policies, and culture.

Question 3

What is the time scale for the outer loop?

Answer 3

• Weeks
• Months (sometimes quarters)

It contrasts with the inner loop (seconds-minutes) and middle loop (hours-days).

Question 4

What are some typical outer-loop questions?

Answer 4

• Should we even use agents for this class of problems?
• What should our default dev+agent workflow look like?
• Which tools and platforms are ‘blessed’?
• What are our safety and security boundaries?
• How do we measure success and failure over time?
• How do we help people adapt?

These questions guide the overall direction and governance of development practices.

Question 5

What are the steps in the outer-loop cycle?

Answer 5

• Observe
• Decide
• Implement
• Socialize & Educate
• Measure & Iterate

This cycle helps in making informed decisions based on gathered data.

Question 6

What is a common outer-loop problem related to fragmentation?

Answer 6

Inconsistency in structuring prompts, logging agent actions, and granting permissions

This leads to difficulties in sharing knowledge and onboarding new team members.

Question 7

What does the outer loop do regarding shadow IT and risky agents?

Answer 7

Defines governance for agent capabilities and protects sensitive systems

It ensures a central view of agent access and actions.

Question 8

What is the outer loop’s role in addressing vendor lock-in and model drift?

Answer 8

Encourages portable patterns and plans for multi-model/multi-vendor scenarios

This helps mitigate risks associated with dependency on a single vendor.

Question 9

What are the standard repo scaffolds for agent use?

Answer 9

• AGENTS.md – guidelines for agent operation
• prompts/ – versioned templates for workflows
• WORKLOG.md – logs of sessions and decisions

These scaffolds help maintain consistency across repositories.

Question 10

What is the purpose of having a platform/guild in the outer loop?

Answer 10

To evolve AGENT patterns, maintain shared tools, and curate training material

This ensures ownership and accountability in managing agent practices.

Question 11

What does the standard permission model define?

Answer 11

• Green – agent can read/write
• Yellow – agent proposes; humans apply
• Red – agent read-only (if at all)

This model helps manage risk and access control across projects.

Question 12

What metrics should the outer loop focus on beyond cool demos?

Answer 12

• Time from ticket open → merge
• Defect/incident rates before vs after agent usage
• AI cost per feature or per team
• Developer satisfaction

These metrics provide insights into the effectiveness of agent integration.

Question 13

What is the outer loop’s job regarding culture lag?

Answer 13

Align culture and incentives with the reality of agents

This includes recognizing prompt design and agent workflows as real engineering work.

Question 14

What is the outer loop primarily responsible for?

Answer 14

Setting the rules of the game and the shape of the playing field

It influences the overall development environment and practices.

Question 15

What are the Outer Developer Loop realities focused on?

Answer 15

Ecosystem: architecture, governance, and economics of agents in your stack

This level involves understanding the broader context in which development occurs.

Question 16

What is a critical aspect of permission models and governance in the Outer Developer Loop?

Answer 16

Defining what agents are allowed to touch and who approves expansions

Clear boundaries are essential to avoid shutdowns by SRE/security or developer hesitance.

Question 17

What can happen without clear boundaries in the Outer Developer Loop?

Answer 17

• SRE/security shuts you down
• Developers are afraid to run agents on important systems

This can lead to inefficiencies and hinder development processes.

Question 18

What does the Outer Loop define regarding zones of trust?

Answer 18

• Scratch repos
• Staging DBs
• Production read-only

These zones help manage where agents can operate safely.

Question 19

In the Outer Developer Loop, how do you design human approval for new capabilities?

Answer 19

By establishing processes for sign-offs, such as allowing an agent to edit CI configs

This ensures accountability and security in agent operations.

Question 20

In economics and sustainability, the question shifts from “is this cool?” to what?

Answer 20

“is this cost-effective compared to traditional approaches?”

This shift indicates a focus on practicality and efficiency in decision-making.

Question 21

What slows down the workflow in economics and sustainability?

Answer 21

A workflow that feels magical individually may be unsustainable at scale

This highlights the challenges of scaling innovative solutions.

Question 22

What are the outer loop decisions in the context of economics and sustainability?

Answer 22

• Invest in prompt / workflow refinement
• Invest in smaller specialized models
• Invest in more powerful general-purpose models

These decisions impact the overall strategy and resource allocation.

Question 23

How do you begin to treat agent usage in economics and sustainability?

Answer 23

Like any other infra: budget, alerts, optimization

This approach emphasizes the need for structured management of resources.

Question 24

What are the architectural choices that impact the inner and middle loop?

Answer 24

• Orchestrator
• Memory system
• Tool registry
• Repositories

These decisions shape the development process and can lead to costly rewrites if poor choices are made.

Question 25

A poor early choice in architectural decisions can lead to _______ later.

Answer 25

costly rewrites ## Footnote This can occur due to wrong orchestrator selection, unclear memory models, or lack of conventions.

Question 26

What does the **comprehensive view** include regarding architectural decisions?

Answer 26

* Beads * AGENTS.md * LangGraph * Temporal/“not Temporal” decisions ## Footnote These elements are crucial for making informed architectural choices.

Question 27

The **outer loop** in architectural choices is focused on choosing patterns that make what simpler?

Answer 27

middle/inner loops ## Footnote The goal is to avoid adding complexity to the development process.

Question 28

What is the **system-level behavior** for idle time that is desired?

Answer 28

* Triaging backlog issues * Running periodic health checks * Fixing low-risk lints/docs ## Footnote This behavior aims to improve system efficiency by proactively addressing issues rather than waiting for demand.

Question 29

What slows down the system when agents are always **'on demand'**?

Answer 29

Lack of proactive improvement ## Footnote Without proactive measures, the system cannot effectively enhance its performance.

Question 30

What is the **outer loop** responsible for in system management?

Answer 30

Deciding on proactive work delegation ## Footnote The outer loop helps determine which tasks can be safely automated and which require human intervention.

Question 31

What are the **guardrails** designed for in system orchestration?

Answer 31

* Safe to auto-launch tasks * Tasks that require human trigger ## Footnote Guardrails help maintain control over automated processes and ensure safety.

Question 32

What is the reality regarding **human processes and culture** in teams?

Answer 32

Optimized for 'humans writing code' ## Footnote This optimization does not account for the orchestration of agents, leading to inefficiencies.

Question 33

What type of **friction** is caused by existing processes in teams?

Answer 33

* PR templates assuming manual authorship * Review processes not acknowledging AI-generated changes * Performance metrics undervaluing orchestration skills ## Footnote These frictions hinder the integration of AI and automation in development workflows.

Question 34

What is the **purpose** of defining agents in your stack?

Answer 34

Productivity, quality, learning, etc. ## Footnote Agents exist to enhance various aspects of the development and operational processes.

Question 35

What are the **non-goals** of agents?

Answer 35

* Direct prod DB writes * Handling secrets ## Footnote Agents should not be used for sensitive operations that could compromise security.

Question 36

Define the **risk appetite** in the context of agents.

Answer 36

Roughly, what level of breakage/cost is acceptable in green zones. ## Footnote This helps in making informed decisions regarding agent operations.

Question 37

What is the first step in **permissions & governance**?

Answer 37

Define Zones of Trust (and keep them stable) ## Footnote Establishing clear zones helps manage agent capabilities effectively.

Question 38

What are the **three zones** of trust?

Answer 38

* Green * Yellow * Red ## Footnote Each zone has specific permissions and controls for agent operations.

Question 39

In the **Green zone**, what can an agent do?

Answer 39

* Read/write feature branches * Read/write test data * Read/write docs * Read/write staging-only configs ## Footnote This zone allows agents to operate freely within non-production environments.

Question 40

In the **Yellow zone**, what is the agent's capability?

Answer 40

Agent proposes, human applies ## Footnote This zone requires human oversight for changes to ensure safety.

Question 41

In the **Red zone**, what is the agent's access level?

Answer 41

Read-only (if at all) ## Footnote This zone is highly restricted to protect sensitive information.

Question 42

What is required for any requested change to a zone?

Answer 42

* A short justification * A human approver ## Footnote This process ensures accountability and risk management.

Question 43

What should be logged in **AGENTS_GOVERNANCE.md**?

Answer 43

* Date * Change * Rationale * Owner ## Footnote Logging changes provides a clear history of governance decisions.

Question 44

How can you **bake zones** into the system?

Answer 44

* AGENTS.md in each repo * Standard prompts * CLI tooling ## Footnote These methods help enforce the defined zones consistently.

Question 45

How does defining zones avoid **pain** in agent operations?

Answer 45

Prevents ambiguity about agent capabilities ## Footnote Clear definitions help avoid security blocks and encourage developer use.

Question 46

What do SRE/security teams see through the defined process?

Answer 46

A clear process for expanding agent capabilities ## Footnote This transparency helps in making informed decisions rather than outright refusals.

Question 47

What is the purpose of **active controls** in establishing an economic model?

Answer 47

* Pull basic metrics * Classify workflows * Decide on model usage * Set policies ## Footnote Active controls help in monitoring and managing AI spending effectively.

Question 48

List the categories for classifying **workflows** based on value.

Answer 48

* High-value * Medium-value * Low-value ## Footnote This classification helps determine the appropriate model and spending for different tasks.

Question 49

What are examples of **high-value workflows**?

Answer 49

* Critical refactors * Complex debugging * Deep design work ## Footnote High-value workflows justify more spending on powerful models.

Question 50

What should be done if a workflow costs more than **$N/month**?

Answer 50

Review prompts and batching ## Footnote This policy helps in managing costs effectively.

Question 51

What is the recommended **default model** for code refactors?

Answer 51

Model X ## Footnote Upgrade to Model Y only on request.

Question 52

What is the purpose of adding a **cost awareness** section to AGENTS_GOVERNANCE.md?

Answer 52

* Identify workloads that must stay cheap * Identify workloads allowed to be premium ## Footnote This section helps in maintaining financial sustainability.

Question 53

True or false: The goal of passive scaffolding is to avoid financial unsustainability in workflows.

Answer 53

TRUE ## Footnote It encourages questioning the necessity of using more expensive models.

Question 54

What should be included in **prompt templates** for model selection?

Answer 54

Model selection hints ## Footnote This helps in defaulting to cheaper models unless a more powerful model is necessary.

Question 55

What metrics should be pulled regarding **AI spend**?

Answer 55

* Total AI spend by project/team * Spend by model tier * Spend by use case * Failed calls due to rate limits/quotas ## Footnote These metrics provide insights into spending patterns and areas for improvement.

Question 56

What is the purpose of maintaining a **“Blessed Patterns & Components” Catalog**?

Answer 56

To review and standardize components for new projects ## Footnote This catalog helps in simplifying processes and avoiding unnecessary lock-in.

Question 57

What should be reviewed every quarter or after major changes?

Answer 57

* Current stack for agents * Orchestrator * Memory/context store * Tool registry pattern * Repo conventions * Integration points ## Footnote Regular reviews help identify friction points and opportunities for simplification.

Question 58

What questions should be asked for each component during the review?

Answer 58

* Does this simplify inner/middle loops, or add friction? * Are we locked in more than we need to be? * Are there obvious, simpler alternatives? ## Footnote These questions guide decision-making regarding component usage.

Question 59

What decisions should be made during the component review?

Answer 59

* Components to standardize * Components to sunset or fence off * Tiny experiments to run before the next review ## Footnote These decisions help streamline future projects and reduce complexity.

Question 60

What is the purpose of **passive scaffolding**?

Answer 60

To provide defaults for new projects and facilitate discussions about alternatives ## Footnote This approach ensures consistency and reduces the need for rediscovery of workable patterns.

Question 61

What should be abstracted behind small libraries or wrapper APIs?

Answer 61

Vendor-specific calls ## Footnote This abstraction allows for easier swapping of providers without requiring a full rewrite.

Question 62

How does avoiding hard-wiring every inner loop to one orchestration library help?

Answer 62

Prevents becoming overly dependent on a single library ## Footnote This strategy mitigates risks associated with vendor lock-in.

Question 63

What is the benefit of starting new projects on established patterns?

Answer 63

They begin on rails that are known to be decent ## Footnote This reduces the time and effort needed to establish workable patterns.

Question 64

Define a **“Safe Tasks for Idle Time” Catalog**.

Answer 64

A catalog that lists tasks that are: * Low-risk * Beneficial if done gradually * Safe to revert ## Footnote Examples include linting, doc updates, generating test skeletons, triaging backlog, and running health checks.

Question 65

What are examples of **safe tasks** for idle time?

Answer 65

* Linting / formatting * Doc updates from code comments * Generating or refreshing test skeletons * Triaging backlog * Running non-destructive health checks ## Footnote These tasks are designed to be low-risk and beneficial when done gradually.

Question 66

For each safe task, specify what must be included in the catalog.

Answer 66

* Applicable systems/repos * Frequency of execution (e.g., nightly, weekly) * Proof of work (PRs, reports, logs) ## Footnote This ensures clarity on how and when tasks are performed.

Question 67

Decide where **automation** is allowed regarding idle tasks.

Answer 67

* Agents may automatically open PRs for lint-only changes * Agents may never auto-merge; human review required ## Footnote This establishes clear boundaries for automated actions.

Question 68

What are the basic **guardrails** for passive scaffolding?

Answer 68

* Idle agents operate only on green-zone resources * They write to branches or open PRs, never direct to main ## Footnote This helps maintain control over code changes.

Question 69

How does this approach **avoid pain**?

Answer 69

* Continuous incremental improvements without rogue agents * Conscious decision-making on safe background tasks ## Footnote This prevents unexpected issues from maintenance agents affecting critical systems.

Question 70

What should be updated in **PR templates** regarding AI assistance?

Answer 70

* Ask if AI assistance was used * Require a brief note if large chunks are agent-generated * Encourage attaching agent-generated logs or summaries ## Footnote These updates help acknowledge the role of AI in contributions.

Question 71

In code review guidelines, how should **AI-generated code** be treated?

Answer 71

* Review with the same or more scrutiny as human-written code * Spot-check for hallucinated abstractions or invented APIs * Look for consistency with established patterns ## Footnote This ensures quality and reliability in code contributions.

Question 72

What should postmortems include regarding **incident response**?

Answer 72

* Was an agent involved? * Did our guardrails fail, or were they missing? ## Footnote This helps in understanding the role of AI agents in incidents.

Question 73

What are some recognized contributions in **performance & growth expectations**?

Answer 73

* Prompt design * Agent orchestration * Guardrail design * AGENTS.md stewardship ## Footnote These elements are considered legitimate engineering contributions.

Question 74

What should be included in **internal playbooks** regarding agents?

Answer 74

* How we use agents for feature work * How to safely do refactors with agents * How to document AI use in PRs ## Footnote These playbooks guide safe and effective use of AI agents.

Question 75

What is the purpose of providing **example repos**?

Answer 75

* Good AGENTS.md * Sensible prompts * Annotated PRs containing agent-generated code ## Footnote Example repositories serve as models for best practices in AI integration.

Question 76

How does acknowledging AI contributions help avoid **pain** in the development process?

Answer 76

* Prevents invisible AI contributions * Engineers feel mastering agent workflows is part of the job * Reduces cultural friction with explicit expectations ## Footnote Clear acknowledgment fosters a better working environment.

Question 77

What is the purpose of conducting a **short outer-loop retro** every N weeks/months?

Answer 77

* Identify time/effort savings * Recognize incidents or extra work * Monitor unexpected cost spikes or rate limits * Share good patterns created by teams ## Footnote This process helps in continuously improving operations and governance.

Question 78

What should findings from the outer-loop retro be turned into?

Answer 78

* Updates to AGENTS_GOVERNANCE.md * Updates to PLATFORM_PATTERNS.md * New or refined prompt templates * Adjusted zones of trust or idle-task rules * Training or documentation ## Footnote These updates help in refining processes and improving efficiency.

Question 79

What is maintained at the top of **AGENTS_GOVERNANCE.md**?

Answer 79

A simple 'Changelog for Agent Policies' ## Footnote This changelog includes date, change, rationale, and a link to retro notes.

Question 80

Fill in the blank: The outer-loop retro helps turn each quarter’s pain into next quarter’s _______.

Answer 80

guardrail ## Footnote This concept emphasizes learning from past experiences to improve future operations.

Question 81

What does the **green** status indicate in permissions and governance?

Answer 81

Agent can read/write ## Footnote Includes feature branches, test data & fixtures, docs and comments, staging-only configs.

Question 82

What does the **yellow** status indicate in permissions and governance?

Answer 82

Agent proposes, you apply ## Footnote Includes CI/CD pipelines, Terraform/infra code, shared libraries, and database migrations.

Question 83

What does the **red** status indicate in permissions and governance?

Answer 83

Read-only or off-limits ## Footnote Includes production DBs, secrets, security policies, and PII/sensitive data.

Question 84

Where should the permissions and governance policy be documented?

Answer 84

AGENTS_GOVERNANCE.md or at the top of AGENTS.md ## Footnote Treat it as law and do not rely on memory.

Question 85

What is the purpose of a **capability registry** in permissions and governance?

Answer 85

To keep track of agent capabilities ## Footnote Helps avoid 'agent creep' into dangerous territory.

Question 86

What should you consider when allowing agents to do something new?

Answer 86

* What could go wrong? * How will I notice if it does? * How would I roll back? ## Footnote This strategy helps manage risks associated with agent permissions.

Question 87

List the **agent capabilities** that may be allowed.

Answer 87

* Edit code in feature branches of repo A * Generate tests * Update docs ## Footnote These capabilities are documented in AGENTS_GOVERNANCE.md.

Question 88

What actions are agents **not allowed** to perform?

Answer 88

* Direct writes to production systems * Read customer PII ## Footnote These restrictions help maintain security and data integrity.

Question 89

True or false: The **yellow** status allows agents to directly write to production systems.

Answer 89

FALSE ## Footnote Yellow status means agents can propose changes, but not apply them directly.

Question 90

What is the first principle of **economics** regarding models?

Answer 90

Treat models like infrastructure, not magic ## Footnote This emphasizes the importance of budgeting and evaluating the cost-effectiveness of workflows.

Question 91

What should you set for each project or month according to the economic strategy?

Answer 91

Rough budgets ## Footnote Example: “This project gets about $X/month of AI spend.”

Question 92

What types of tasks should be allowed to be ‘**expensive**’?

Answer 92

* Bulk refactor * Complex tasks ## Footnote Daily small edits should be kept cheap.

Question 93

At the end of each month/phase, what two questions should you ask regarding workflows?

Answer 93

* Which workflows were worth the cost? * Which felt overkill for what they delivered? ## Footnote This helps in adjusting habits and optimizing costs.

Question 94

How should you choose models according to the economic strategy?

Answer 94

By workflow, not by habit ## Footnote Avoid defaulting to always using the biggest model.

Question 95

What type of model should be used for **boilerplate** tasks?

Answer 95

Cheap/small model ## Footnote This includes tasks like doc generation and format conversions.

Question 96

What type of model is recommended for **cross-service architecture questions**?

Answer 96

Big/expensive model ## Footnote This is suitable for complex tasks like gnarly debugging.

Question 97

What strategy should be included in your prompt templates regarding model usage?

Answer 97

Use model X by default; upgrade to Y only if you’re doing deep reasoning or stuck ## Footnote This encourages efficient model selection.

Question 98

What should you periodically do to **expensive workflows**?

Answer 98

Kill or refactor ## Footnote Regularly assess high-usage workflows for potential improvements.

Question 99

What are some strategies to consider for improving high-usage workflows?

Answer 99

* Cached * Batched * Partially done with scripts or grep ## Footnote Look for simpler prompts or patterns that achieve the same outcome.

Question 100

What recurring task should be made to improve workflow efficiency?

Answer 100

Kill or shrink one wasteful workflow ## Footnote This task can lead to quick payoffs in efficiency.

Question 101

What is the **minimal structure** recommended for all agent-aware repositories?

Answer 101

* AGENTS.md * prompts/ * WORKLOG.md (optional) ## Footnote Standardizing this structure allows for easier reuse and migration across projects.

Question 102

What should you do with **vendor-specific** code?

Answer 102

Wrap it behind: * small helper functions * a simple client module * CLI wrappers ## Footnote This approach helps avoid scattering raw provider-specific code throughout the project.

Question 103

True or false: It is advisable to build a **huge agent platform** right away.

Answer 103

FALSE ## Footnote Start with simple scripts and only add complexity when specific bottlenecks are identified.

Question 104

What should you start with before adding complex features like **multi-agent graphs**?

Answer 104

* Simple scripts * Prompt templates * Logs * Light-weight orchestrator (if helpful) ## Footnote This strategy emphasizes gradual development based on identified needs.

Question 105

What is the key question to ask before adding new architectural pieces?

Answer 105

What concrete bottleneck does this new architectural piece solve? ## Footnote If you can't answer this, it's better not to add it yet.

Question 106

What is the purpose of curating an **“auto-safe” task list**?

Answer 106

To explicitly decide which kinds of tasks agents can do without supervision ## Footnote This list helps maintain control over automated tasks and ensures safety.

Question 107

Give examples of **auto-safe tasks**.

Answer 107

* Linting / formatting * Regenerating docs from comments * Adding missing docstrings * Running read-only health checks and producing reports * Triaging issues (adding labels, grouping, summarizing) ## Footnote These tasks can be performed by agents without direct oversight.

Question 108

What are examples of tasks that are **not auto-safe**?

Answer 108

* Changing business logic * Modifying schema/migrations * Touching production configs ## Footnote These tasks require careful oversight due to their potential impact.

Question 109

What is the strategy for managing **auto-safe tasks**?

Answer 109

Put an **“Auto-safe tasks”** section in AGENTS_GOVERNANCE.md ## Footnote This ensures that idle/autonomous agents do not perform tasks outside the approved list.

Question 110

What is the rule regarding how idle/auto agents should handle work?

Answer 110

* Work in a branch * Open a PR * Clearly label it as “agent-generated maintenance” ## Footnote This process prevents direct writes to main or production configurations.

Question 111

True or false: Idle or auto agents can write directly to main or production config.

Answer 111

FALSE ## Footnote The personal rule states that no agent should write directly to these configurations to prevent damage.

Question 112

What is the purpose of capping how much **auto-change** can land per cycle?

Answer 112

To avoid **“death by a thousand tiny PRs”** ## Footnote This helps manage the volume and impact of automated changes.

Question 113

What limitations can be set on auto PRs?

Answer 113

* Frequency of opening (e.g., nightly/weekly) * Size limits (e.g., <= N files, <= X LOC) ## Footnote These limitations make it easier to manage and revert changes if necessary.

Question 114

What should you do if you find auto-changes **annoying or noisy**?

Answer 114

Turn them off first, then refine ## Footnote This approach prevents enduring chaos due to sunk-cost guilt.

Question 115

What should you note in **PR descriptions** when agents are used?

Answer 115

Indicate the sections generated with agent and the prompt used ## Footnote Example: “Sections A & B generated with agent, prompt in prompts/refactor-v2.md.”

Question 116

How should you review **AI-generated changes**?

Answer 116

As if they came from a junior dev ## Footnote Check APIs, hidden assumptions, and invented abstractions.

Question 117

What strategy can be added to your **PR template**?

Answer 117

Add a checkbox for AI assistance used ## Footnote This encourages careful consideration of AI-generated changes.

Question 118

What questions should be asked during **retros and incident reviews**?

Answer 118

* Did an agent contribute to this problem? * Did our guardrails fail, or were they missing? ## Footnote These questions help identify the role of AI in incidents.

Question 119

What should you do if an **agent contributed** to a problem?

Answer 119

* Add/adjust a rule in AGENTS_GOVERNANCE.md * Update a prompt template * Tighten green/yellow/red for that area ## Footnote This approach helps improve guardrails.

Question 120

What should you track and value as **real engineering work**?

Answer 120

* Improved prompt templates * Better AGENTS.md * Safer workflows * Reusable patterns developed ## Footnote Recognizing these contributions enhances the value of AI involvement.

Question 121

What should you write at the end of a month/quarter for **AI/agent highlights**?

Answer 121

* Patterns discovered or improved * Guardrails added * Workflows that are now smoother or safer ## Footnote This keeps you in architect mode, focusing on improvements.

Question 122

Four rules of thumb governing your decisions in the outer loop

Answer 122

1) Start in the smallest blast radius. * New workflows live in toy projects / side repos first, then staging, then real systems. 2) Prefer reversible decisions. * New config file? Good....Massive cross-repo rewrite tied to one tool? Bad. 3) Always know how to kill it. Any new autonomous/idle behavior should have: * a single flag/setting to turn off, * a clear place to revoke its permissions. 4) If you can’t explain it, don’t approve it. If you don’t understand: * what an agent is allowed to do, * where it runs, * how it’s observed, …it’s not ready to exist in your outer loop.