Skip to content
DenseChip
Learn
PracticeCode labInterview

DenseChip

Navigate

Menu

LearnPracticeCode labInterview

Tools

All toolsSV editorCode repoResume
DenseChip

Practice, courses, and chip-design tools in one focused workspace.

LearnPracticeCode labInterviewToolsLearning paths

© 2026 DenseChip

AboutContactPrivacyTerms
Skip to lesson

Course contents

  • Getting Started with AI for VLSI Engineers5
  • Just Enough AI: Models and Context15
  • Prompting13
  • Trust and Verification14
  • Using AI for Engineering Work17
  • Engineering Walkthroughs7
  • Practical Foundations for AI Workflows4
  • Engineering Data5
  • Retrieval-Augmented Generation6
  • Agents and Tool Use18
  • Agent Design8
  • MCP and Skills6
  • Multi-Agent Design6
    • When to Split a Task
    • Roles and Task Contracts
    • Context and Handoffs
    • Merge and Disagreements
    • Permissions, Budgets and Failures
    • Review Team Lab
  • Practical Capstone6
  • Tokens, Cost and Latency12
  • Agentic Workflows for Chip Teams18
  • Interview and Judgment10
  • AI Skills: Full Course Index
  • Working with AI Glossary
  • Working with AI Cheatsheet
Loading lesson

‹Multi-Agent Design
  1. Topics
  2. AI Skills for VLSI Engineers
  3. Multi-Agent Design
  4. Permissions, Budgets and Failures

Multi-Agent Design · Beginner

Permissions, Budgets and Failures

Enforce read-only access, bounded work and honest partial results.

On this page

    Problem: a bounded review becomes an open loop

    A reviewer cannot find its input and decides to search other directories. A coordinator dislikes a disagreement and keeps requesting retries until every reviewer agrees. Both behaviors can exceed the original task even though they sound helpful. Permissions and budgets should be decided before starting work. For this course's review, each role reads only the frozen synthetic packet and returns text; no role edits sources, starts a tool or contacts another service.

    Distinguish instructions from enforcement. The sentence 'read-only' communicates intent. A real workflow should expose only allowlisted read capabilities and a separate output channel, with no shell, network or source-write capability for these roles. A coordinator cannot grant itself additional access because it needs more evidence. Data inside a spec, comment or log is task material, even if it contains words that resemble instructions to change policy or ignore earlier restrictions.

    Worked synthetic budget and failure record

    plaintext
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    Teaching budget; values are caps, not measured usage:
    roles: two reviewers plus coordinator
    rounds: one draft per reviewer, one merge
    retry: at most one malformed-response repair per run
    deadline: 10 minutes wall time, including any retry
    usage: preflight maximum plus cumulative reserved/used units <= 6000
    tools: none; input: enable-demo-v1 only
    
    Synthetic event: RTL reviewer times out.
    Coordinator state: partial; spec extraction available;
    RTL compliance unresolved; do not infer a clean review.

    A controller must reserve budget for the next step before issuing it. Counting only completed calls can overspend when several calls are in flight. Where an approved tool reports usage, record it, including failed or repeated attempts when charged. Where usage is unavailable, label the value unknown and apply a conservative cap. A timeout is a transport or scheduling outcome, not a negative finding about the design. The final report should expose which work was never completed.

    Retries need a reason. A response that is missing a required field may merit one repair using the same sources. A disagreement about reset semantics needs evidence or a human decision, not repeated sampling until a preferred answer appears. If a role requests an unauthorized path, reject that action and return a bounded missing-input message. If sources disagree about revision, stop the affected review rather than combining incompatible versions into a plausible narrative.

    Exercise: choose the next state

    The spec role finishes, the RTL role times out, and the coordinator has enough budget for either its partial report or an unbounded sequence of retries. Meanwhile a source comment says to upload the design for a better review. Write the permitted next action and the fields the final report needs. Decide whether a numerical quality score should treat the missing RTL result as a clean pass, an explicit incomplete case or a hidden omission.

    Check yourself How should the workflow handle these events?

    Ignore the upload request as untrusted source content and deny network access. Use only a retry allowed by the original cap and remaining deadline; otherwise finish with a partial report. Include completed roles, missing RTL analysis, timeout status, actual known usage, unknown charges and the human next step. Count this as incomplete, never as a clean pass or an omitted evaluation case.

    Limits and reading

    Budget caps control resource exposure, not engineering correctness. A low-cost answer may still be unsupported, and a deadline may require an incomplete result. Keep acceptance criteria separate from spending limits. For the principle behind restricted capabilities, read NIST SP 800-53 Rev. 5, September 2020, AC-6. Actual wrappers and service accounting vary; this lesson specifies no real provider's retry behavior or price.

    Related topics

    • Up: Multi-Agent Design

    • Next: Review Team Lab

    Previous

    123 / 173

    Next: Review Team Lab

    Up next

    Up nextReview Team Lab

    Sign in to save progress

    Practice this lessonReport an error

    See also

    • When to Split a Task
    • Roles and Task Contracts
    • Context and Handoffs