Exercise Bank — Why More Than One Agent?

The printed Chapter 1 keeps Exercises 1–6; the bank continues from Exercise 7.

Exercise 7. A documentation overhaul is three-fifths parallelisable (p = 0.6), and the team that would take it on coordinates at \kappa = 0.01. (a) Compute T(2) and T(4) and the corresponding speedups. (b) Locate n^{*} by evaluating S(n) up to n = 6, and show — by comparing what the step from n to n + 1 saves in waiting with what it adds in tax — that no larger team needs checking. (c) What fraction of the tax-free ceiling 1/(1 - p) does the best team actually collect?

Exercise 8. (a) Show from the model that

T(n) - T(1) \;=\; \frac{(n - 1)\bigl(\kappa n^{2} - 2p\bigr)}{2n},

so that a team of n beats a single agent exactly when n < \sqrt{2p/\kappa}. (b) Deduce that a pair pays its way exactly when \kappa < p/2, and that if the pair does not pay, no larger team will. (c) A tightly coupled schema migration has p = 0.2 and \kappa = 0.15; a well-partitioned localisation job has p = 0.8 and \kappa = 0.1. For each, list every team size that beats a single agent, and say what happens at n = 4 on the localisation job. (d) Which question of the checklist in Section 1.6 has this inequality made quantitative — and for which currency alone?

Exercise 9. Wire the team as a star instead: every worker talks only to the orchestrator, so the tax falls on n - 1 links, c(n) = \kappa(n - 1). (a) Derive the continuous optimum n^{*} \approx \sqrt{p/\kappa}. (b) For a code-migration task with p = 0.85 and \kappa = 0.003, find the exact optimum and the peak speedup under both wirings — fully connected and star — and compare them. (c) The linear tax prices the links but not the hub: say what the star costs the orchestrator itself, and which of the four marks of Section 1.1 its context window thereby becomes an instance of. Section 8.6 takes the wiring question up properly.

Exercise 10. A vendor markets DocuSwarm, “a five-agent document-intelligence platform”: an intake agent classifies each incoming document, an extraction agent pulls out its fields, a compliance agent checks them against policy, a summary agent drafts an abstract, and a publishing agent files the result. The five run in that order on every document, each a single model call under a role prompt, and a scheduler moves the documents down the line; nothing may skip, reorder, or repeat a step. (a) Test the platform against the three features of Section 1.3, and give it its honest name and its row in Table 1.2. (b) Make the strongest case that this shape is right for this problem, in the terms of Section 1.6. (c) A new release lets the compliance agent send a document back to extraction with questions, at most twice, and lets the intake agent split a bundled file into sub-documents processed in parallel lanes. For each change, say which defining feature it adds, if any, and rule on whether the release crosses the line into a multi-agent system. (d) Specify the smallest further change that genuinely would cross it, and name the first cost from the ledger of Section 1.5 you would then have to budget for.

Exercise 11. You have timed a report-compilation task on your own infrastructure at several team sizes, in units of the single agent’s time: T(1) = 1.00, T(2) = 0.63, T(3) = 0.51, T(4) = 0.46, T(6) = 0.42, T(8) = 0.43. (a) Show that with T_1 normalised the model is linear in the pair (p, \kappa), namely T(n) = 1 - p(1 - 1/n) + \kappa\, n(n - 1)/2, so that fitting it is least squares rather than a search in the dark. (b) Estimate (p, \kappa) by hand from the n = 2 and n = 4 measurements alone. (c) Write a short standard-library program that fits (p, \kappa) to all six measurements by minimising the sum of squared errors over a grid, and report the fitted pair and the n^{*} it implies. (d) The estimates of (b) and (c) differ; does the implied n^{*}? Use the law of Exercise 2 to explain why n^{*} is the most forgiving quantity this model predicts.

Exercise 12 (lab). The parameters p and \kappa are facts about your task; this exercise measures them. Choose a small real task with visible facets — answering a six-part research question, say, or fixing three unrelated failing tests in a toy repository. (a) Run it with one live agent, and record the wall-clock time and the total tokens. (b) Run it with teams of two and of four — an orchestrator that partitions the facets and merges the answers — holding the model, the per-facet prompts, and the acceptance check fixed, and repeating every configuration at least three times, because single runs are noise; Chapter 21 develops the method properly. (c) Normalise the mean times by T(1), fit (p, \kappa) with the fitter of Exercise 11, and locate your task’s n^{*}. (d) Set the measured token totals against B(n) from Exercise 3: which grows faster, and why? Before spending money, dry-run the design against the scripted, no-network sweep in the companion repository (frontier/scaling_lab/, run as python -m frontier.scaling_lab.run), whose coupled and parallel regimes bracket what to expect; the full instrument — team sizes crossed with topologies — is the capstone lab of Chapter 23. Record the model identifier and the date beside your results.