AI Technology Brief · 11 August 2026
A source-grounded buyer guide to using Claude Projects, Claude Code Skills, MCP connections, and bounded tools for requirements, package, scope, quote, and review preparation while contractors retain source, contractual, commercial, and award authority.
Verified product state
These capabilities come from current Anthropic documentation. They create useful implementation options, not automatic project knowledge or procurement authority.
Anthropic describes Claude Projects as self-contained workspaces with their own chat histories, knowledge bases, and instructions. Uploaded project knowledge provides context; it does not establish that every file is current, complete, permitted, or contractually controlling.
Claude Code Skills use a SKILL.md entry point and can include scripts, templates, examples, and references. Invocation confirms that instructions were loaded, not that the resulting procurement output is correct.
Claude Code can connect to tools, databases, APIs, and event sources through MCP. Anthropic warns buyers to trust each server, consider prompt injection, restrict credentials, and validate tool input and output server-side.
Claude Code is read-only by default and can require approval for edits, commands, broader file access, network calls, and MCP tools. Managed settings and sandboxing can add organizational controls, but users remain responsible for permissions and approvals.
Anthropic states that commercial-product inputs and outputs are not used to train models by default. Feedback, opted-in use, retention, connectors, product tier, contract, and deployment route still need separate review.
Claude Projects, Claude Code, claude.ai Skills, the API, and connected MCP servers do not share one universal file, skill, permission, retention, or execution model. Buyers must verify the selected surface and current terms.
How StructuredLayer structures it
This is StructuredLayer's representative operating architecture. It is not presented as a completed client implementation or offered as a verified savings claim.
Inventory the identified head contract, scope, drawings, specifications, addenda, programme, tender records, and permitted business templates. Preserve source-native IDs, revisions, statuses, dates, permissions, and hashes before extraction.
Prepare product and process requirements with document, revision, page, clause, region, and exact evidence. Keep missing, ambiguous, conflicting, superseded, and unreadable material visible for review.
Map reviewed requirements to candidate subcontract, supplier, material-only, and self-perform packages using stable package IDs. Show unallocated requirements, overlaps, interfaces, exclusions, and assumptions.
Use approved templates and reviewed project requirements to draft concise scope, pricing-schedule, procurement-date, and required-deliverable records. Keep schedule logic, lead times, contractual terms, and professional conclusions proposed.
Extract bidder qualifications, inclusions, exclusions, alternatives, dates, currencies, taxes, validity, programme, warranties, and commercial adjustments into comparable records linked to original quotes and correspondence.
Present unresolved scope, price, programme, legal, technical, safety, quality, and supplier-performance questions to named estimators, commercial managers, project leaders, designers, planners, and other authorized reviewers.
Record the accountable recommendation, approval, negotiation, issue, award, and contract execution in the governing business workflow. Claude does not select the winning bidder or inherit authority to commit the company.
After delivery, reconcile actual cost, duration, scope gaps, supplier performance, variations, and lessons. Only approved, permissioned, versioned learning is promoted to reusable business context; disputed or expired material remains excluded.
Durable records
A buyer-controlled record model lets teams reconcile sources, corrections, reviewers, decisions, and accepted outcomes across Claude, project systems, commercial systems, and future providers.
Requirement ID, project ID, source document and revision, page or clause, requirement type, exact evidence, candidate interpretation, owner, review status, correction, and accepted version.
Package ID, package type, related requirements, included and excluded interfaces, responsible discipline, proposed procurement route, status, reviewer, and accepted package version.
Organization and bidder IDs, quote ID and revision, received time, currency and tax basis, price, validity, inclusions, exclusions, alternatives, qualifications, programme, source link, and review state.
Comparison ID, requirement or scope link, bidder response, candidate normalization, evidence, assumption, deterministic calculation, exception, reviewer correction, and accepted commercial treatment.
Work-item ID, run ID, actor identity, source versions, skill or instruction version, model and tool versions, start and end state, failures, side effects, reviewer, and recovery.
Decision ID, reviewed options, recommendation, unresolved risks, accountable role, approval limit, decision, conditions, effective date, superseded decision, and accepted-output IDs.
Control plane
Evaluation cases
A successful demonstration on clean documents does not establish reliable operation across revisions, bidders, correspondence, commercial calculations, or external tools.
Can the workflow distinguish current, issued, tender, addendum, work-in-progress, reference, and superseded documents rather than choosing the newest filename?
Can it detect duplicate suppliers, renamed projects, reused filenames, revised quotes, and unmatched package IDs without silently merging records?
Does it expose a requirement assigned to no package, two packages, or a package whose bidder expressly excluded it?
Are currency, tax, quantity, unit, rate, alternates, allowances, adjustments, and totals recalculated by deterministic rules and compared with source totals?
Does untrusted content in an email, document, website, or MCP response fail to expand permissions, reveal secrets, change instructions, or cause an external action?
If one attachment, quote, tool, or export fails, does the run preserve completed items, mark the failed scope, avoid duplicate side effects, and support controlled recovery?
Can the user distinguish extraction completion, reviewer acceptance, commercial recommendation, delegated approval, external issue, and executed agreement?
Can an authorized reviewer identify the exact sources, versions, instructions, model, tools, deterministic checks, corrections, and accepted result for a previous decision?
Agent Skills governance
Skills can package instructions, references, scripts, tools, and company-specific procedure. Their invocation, code, permissions, portability, security, output quality, and maintenance require separate controls.
A skill name and description help Claude decide when to load it. Evaluate missed invocation and false invocation separately; direct invocation proves discovery, not output quality.
Store the approved method, schemas, examples, exceptions, review rules, and environment-specific constraints that the base model cannot infer reliably. Do not fill the skill with generic advice.
Keep the main SKILL.md focused and place detailed references, templates, examples, and scripts in supporting files that are loaded only when required.
Use reviewed code for exact calculations, transformations, validation, reconciliation, and file operations. Deterministic code can still contain defects, so version and test it.
A skill's allowed-tools can pre-approve tools for a turn; it does not restrict all other tools. Use managed allow, ask, and deny rules, sandboxing, identity controls, and exact approval outside the skill.
Treat downloaded skills, scripts, plugins, MCP servers, packages, and references as software dependencies. Inspect code, network access, secrets, file scope, licences, updates, and provenance before trust.
Record the skill, instructions, scripts, templates, examples, model, tools, permissions, and evaluation versions used for every consequential run.
Compare a fresh-session baseline with the skill across normal, incomplete, conflicting, malicious, and failure cases. Measure accepted output, correction effort, security behavior, and complete cost.
Agent Skills provides a portable directory format, not identical client behavior. Discovery paths, activation, script runtimes, available tools, workspace trust, cloud filesystem access, and model behavior differ by client.
The format being open does not make every downloaded skill open-source or Apache-licensed. Record the skill's own licence, dependencies, provenance, modification rights, redistribution terms, and update source.
Compatibility metadata documents required runtimes, packages, products, or network access. It documents requirements; it does not enforce them or create them.
Buyer boundaries
It can extract and compare candidate clauses, deadlines, obligations, and correspondence. It does not determine legal interpretation, notice validity, entitlement, privilege, waiver, time bar, or the authorized contractual position.
It can prepare evidence and structure inputs. It does not establish complete scope, measured quantities, productivity, current rates, escalation, risk, contingency, estimate classification, or authority to submit a price.
A separate context or subagent can find inconsistencies, but it may share model weaknesses, instructions, sources, tools, and assumptions. Qualified human review and deterministic checks remain necessary.
Messages can be incomplete, personal, privileged, malicious, informal, superseded, or unauthorized. Capture must preserve identity, thread, attachments, date, participants, permission, and review state.
The draft may omit work, misread interfaces, conflict with governing documents, reproduce an unsuitable template, or allocate risk incorrectly. Issue and contract execution require accountable technical, commercial, and legal review.
Past prices, durations, variations, and supplier performance require normalization, comparability, permission, correction, expiry, and qualified interpretation. Ten examples do not establish a reliable benchmark.
Choose the product boundary
Select the narrowest product surface that satisfies the approved workflow, data, identity, administration, execution, review, and handover requirements.
Useful for bounded document-supported analysis and repeatable project instructions where the selected plan, sharing model, knowledge limits, retention, and permissions fit the work.
Useful where a controlled local or managed project workspace, versioned SKILL.md instructions, scripts, tests, file operations, and permission policy are required.
Useful when approved external systems or tools must be queried or operated. Server trust, schemas, authentication, prompt injection, least privilege, approvals, logging, timeouts, and recovery become part of the system.
Useful for an application-controlled workflow with explicit context assembly, tools, schemas, identity, storage, monitoring, evaluation, and user experience. The buyer owns the surrounding implementation and controls.
Official sources
Product behavior, plan availability, limits, data handling, and permission controls can change. Confirm the selected product surface and applicable agreement.
Recommendation
Begin with requirements extraction or quote normalization, not autonomous scope issue, value engineering, bidder selection, contractual communication, award, or payment. Measure source coverage, field accuracy, unsupported claims, corrections, reviewer effort, complete cost, and accepted outcomes.
Next best page
Move from evaluating the operating conditions to choosing a bounded response and assessing one real workflow.
