Integration Architecture: The Adapter Boundary
Agent-Assisted Engineering Check
Prerequisites
Day 85 frozen charter and acceptance contract; projects/agent_learning source layout.
Learning Objective
Design the integration seam that composes the verified harness (tools, budgets, scorer) with the selected model adapter - adding exactly one bounded tool - without weakening any existing limit.
Instructions
1. Map the components in projects/agent_learning: cli.py entry point, agent.py loop with step/retry budgets and path checks, fixtures.py disposable workspace, the deterministic-v1 adapter, and the independent scorer.
2. Draw the adapter boundary: the adapter proposes actions; the harness validates them, executes bounded tools, and returns structured observations. The model never bypasses validation.
3. Specify the one new bounded tool (for example count_words(note_name) -> int): registered name, typed arguments, fixture-confined path handling, and its own failure contract.
4. Specify the live-adapter slot: the same action schema as deterministic-v1, gated by the ticket-23 authorization contract; the harness cannot tell which adapter produced an action - that opacity is the seam.
5. Write integration_design.md: a text component diagram, the tool contract, and a 'limits preserved' checklist (step budget, retry budget, payload limit, path check, termination conditions).
Practice & Prediction Log
Write the count_words tool contract (name, arguments, return type, error modes) and the limits-preserved checklist proving that swapping adapters cannot raise a budget.
If an action arrives with malformed arguments, who rejects it? The harness - which is why the adapter can stay untrusted.
count_words(note_name: str) -> int; error modes: invalid_arguments (non-string or missing name) and missing_note (name not in the fixture). Limits preserved: max_steps=6, max_retries=2, payload cap, fixture-rooted paths, termination on goal_reached | tool_failure | budget_exhausted - all enforced harness-side.
Produce a design where every control lives harness-side and the adapter is replaceable without touching budgets, paths, or termination.
Authoritative Source Resources & Provenance
Toolformer: Language Models Can Teach Themselves to Use Tools
Relevant Section / Range: Sections 2-3: API-call annotation, sampling, filtering, tool integration
Verified Version & Date: NeurIPS 2023 / arXiv:2302.04761v4 (Verified: 2026-10-30)
Primary reference for model-tool integration with explicit API contracts; informs the capstone's adapter boundary where the harness owns tool validation and the model only proposes calls.
Language-model finetuning, API calls, and tool schemas.
The capstone's tool contract template (name, typed arguments, error modes) is fully specified in the lesson instructions.
Compared Candidate Sources & Selection Analysis (2)
Prompt-time interleaving rather than finetuned tool calls; both define the model-side of the same adapter boundary.
Large API-corpus retrieval; Toolformer's minimal single-tool mechanics match the capstone's bounded tool set.
LLM Powered Autonomous Agents
Relevant Section / Range: Sections: planning, memory, tool use, challenges
Verified Version & Date: Blog post June 23, 2023 (Verified: 2026-10-30)
Widely used survey mapping agent architecture components (planning, memory, tools) and their failure modes; supports the capstone integration architecture review.
Agent loops, tool use, and planning vocabulary.
The capstone architecture lesson specifies the adapter boundary, budgets, and tool contracts directly; no blog content is required offline.
Compared Candidate Sources & Selection Analysis (2)
Open-ended autonomous loop; deliberately excluded as the capstone must remain a bounded, evaluable system.
Task-list autonomy demo; the survey article gives vocabulary while the capstone keeps fixed tasks and budgets.