Preserve intent when choosing factories
Your agent should carry the founder’s requirements into each decision. Structured intake.manufacturingIntent preserves current purpose, quantity/unit, revision, future plans, hard requirements and preferences for RFQ preparation. Arbitrary intake text alone does not establish a verified factory match or delegation policy.
This guide prepares a project RFQ (request for quotation) with selected factories. For the separate capability catalog and saved /run request, use from files to a quote request.
1. Record requirements with evidence
Section titled “1. Record requirements with evidence”For each requirement, keep the value, source, revision and whether it can change. Separate an unknown from permission to choose freely.
| Requirement | Example | Decision rule |
|---|---|---|
| Manufacturing location | US machining required by the founder | Exclude incompatible locations; investigate unknowns |
| Critical dimension | Bore tolerance from released drawing B | Obtain applicable process and inspection evidence |
| Material | Aluminum 6061; substitutions need review | Keep the exact alloy in the RFQ |
| Quantity | 100 units from the current BOM | Ask for pricing at that quantity |
| Quality preference | Dimensional quality before price | Compare acceptance evidence before price |
| Schedule | Desired sample date, still flexible | Preserve as a preference until confirmed |
An agent can read this context from the user’s selected files. It should ask about missing decisions that affect the next step, rather than re-interviewing the founder about facts already present.
Store the reviewed brief and structured manufacturingIntent in the project’s intake, using the project schema in the API reference. Keep current samples, planned pilots and forecasts separate; a forecast is not a current order. Keep a local copy with file hashes and revision references. When updating intake, retrieve and merge the existing object: the API replaces the supplied object rather than merging individual keys.
2. Find and inspect candidates
Section titled “2. Find and inspect candidates”Use the factory network’s supported filters, then inspect each candidate:
{"process":"cnc","page":1,"pageSize":50}Save this as factory-filters.json:
maglev factories list --input factory-filters.json --jsonmaglev factories get FACTORY_UUID --jsonContinue through relevant result pages. city and region filters match recorded text; they do not verify the country of the facility that will make your parts. The factory network has no structured country filter in this release. Confirm the actual production location, including subcontracted work, when location is a requirement.
Engineering partners and prior replies
Section titled “Engineering partners and prior replies”CLI 0.6.14 and MCP 0.2.14 accept a returned eng- engineering-partner directory ID in the same read operation as mfg-, int- and UUID references. An identifier prefix does not verify the partner’s role, legal identity, facility or capabilities.
MCP0.2.14 also accepts answeredUs: true in list_manufacturers, matching the existing CLI filter. It selects a recorded prior reply. Omit it to search all records; false does not mean “has not replied” and is rejected. A prior reply does not establish current capacity, a partnership or permission to contact anyone.
These are read-only client changes. They preserve server scope checks and returned unknowns. They do not change the API’s filtering, field visibility or review policy. Use returned records and their evidence when assessing fit; source tests are not proof of a reviewed supplier network.
For each hard requirement, classify the candidate as supported, incompatible, or unknown, with a source. A profile’s confidence, prior reply, certificate count or website is not a substitute for product-specific evidence. An unknown candidate needs investigation before it can satisfy a hard requirement.
If no candidate fits, keep that result. Ask about expanding the search or changing the requirement only when the user has not already given that discretion. Do not silently switch a US-only job to another country.
3. Select factories explicitly
Section titled “3. Select factories explicitly”The current quote_request action can choose a shortlist automatically from process and scope. That automatic selection does not enforce project intake geography or quality requirements. Its priority parameter carries the buyer’s preference into the RFQ. quality, lead_time and price do not produce a verified ranking: directory order is preserved because comparable supplier evidence is unavailable. The result reports priorityRanking: not_verified.
Use the returned factory UUIDs in input.factoryIds after reviewing fit. The action accepts up to five. Stable returned directory IDs are also supported; legacy names must resolve uniquely. Use returned identifiers to avoid ambiguous matching. A missing or empty factoryIds array enables automatic shortlisting; it does not mean “contact nobody.”
4. Include the requirements in the RFQ input
Section titled “4. Include the requirements in the RFQ input”Carry applicable facts into parts[].notes, material, finish, quantities and dfmQuestions. Project intake is not automatically copied into this action’s RFQ prompt. Read the quote request schema for the exact limits.
For example, a part’s supported fields can say:
{ "name": "Sensor enclosure, revision B", "process": "cnc", "material": "Aluminum 6061", "quantityPerUnit": 1, "notes": "US machining required. No alloy substitutions without review. Quote against released drawing B and identify the manufacturing location. Dimensional acceptance criteria must be confirmed before production."}This is illustrative text, not evidence that drawings were supplied. Local filenames do not upload files. Set drawingsStatus to the actual sharing state; an NDA draft does not establish a signed agreement. Share the agreed file set through an authorized channel and identify the revision in the message.
Use dfmQuestions to ask what evidence is missing, for example: “Confirm which operations are subcontracted, the inspection method for critical dimensions, and any drawing ambiguities before quoting.” Keep requests within the user’s communication and confidentiality instructions.
5. Review the generated draft
Section titled “5. Review the generated draft”Before any permitted dispatch, verify:
- The returned shortlist contains exactly the intended factory UUIDs; resolve
unresolvedFactoryIds. - The English and Chinese RFQ preserve quantity, revision, location, materials, acceptance requirements and authorized tradeoffs.
- The actual file-sharing state matches the message.
- Missing facts remain questions, and no invented price or delivery commitment appears.
Inspect missingFields, reviewRequirements, the current-quantity source and unresolved IDs. Missing current context prevents drafting. Read the individual deliveries. Honor the user’s existing coordination authority; a permission already granted does not need to be requested again. Approval with a live key can send or queue a delivery, as explained in projects and actions.
6. Compare the replies on the same basis
Section titled “6. Compare the replies on the same basis”Follow review supplier quotes for an executable example and a comparison checklist. quote_record structures a supplied supplier reply. Keep that original reply with its date. Compare quantity, currency, Incoterm, tooling, sample costs, validity, lead time, exclusions and quality evidence before comparing the price. Missing information remains unknown.
If the cheapest offer fails a hard requirement, it is not the best offer for this brief. If two offers satisfy the requirements, apply the founder’s preference order and present the tradeoff with its evidence.