
Agents & automation
CastLink AutoQuote
Reads a drawing from email, checks 49 rules, and drafts a quote for CEO approval.
CastLink AutoQuote is a teaching build around an IIM Calcutta case on an aluminium-casting manufacturer. An agent reads a customer's drawing and quantity from email, checks the quotation rules, costs the job and drafts a quote that the CEO approves. No deployment outcome is recorded for this build.
The problem
The problem comes from an IIM Calcutta teaching case, MC356-26, about an aluminium-casting manufacturer. In the case, the firm receives about 100 to 150 quotation requests a month as 2D drawings. For each one, engineers meet for 30 to 45 minutes to check whether the part can be made and to list questions for the customer. A quote takes two to three weeks, and only about five requests a month become orders.
The hard part is not the arithmetic. It is that the knowledge of how to read a drawing sits in engineers’ heads. The case makes the point that the AI part is the easy part, and that getting people to say how they read a drawing is the work.
What I built
I built the system as a worked exercise for the case. It starts from a customer’s email.
An agent picks up the email and finds the drawing and the quantity. Two drawing readers then work independently and blind to each other, and a reconcile script compares what they read.
The extracted drawing is checked against 49 quotation rules. Costing uses 12 rate cards, and a Python costing step produces the price. The result is a drafted quote that goes to the CEO for approval. The system proposes; a person decides.
It is built from Claude Code agents with Gmail access and Python scripts. It runs on Claude, and it is not a small-model system.
How it performed
I have no performance measurement for this build. I did not record how often the two readers agree, how often the rules catch a real problem, or how close the costs come to a human estimator’s. It has not been deployed in a firm, and no deployment outcome is recorded. It is a teaching reference that shows the structure.
What I learned
The reason for two blind readers and a reconcile step is that a single model reading a drawing and answering confidently gives no signal about where it might be wrong. Two readers that disagree do. I have not measured how often that happens, so this is the design argument, not a result.
Rules written down are the real asset. The 49 rules and 12 rate cards are the engineers’ judgement, made explicit, and the agents are only as good as they are. That matches the case’s lesson that the difficult step is documenting how the work is actually done.
The approval step is not decoration. Putting the CEO at the end keeps the accountable person in the loop, and makes it safe to let the agents do the first draft.
Finally, a faster process is not a redesigned one. The case describes a team that got faster but kept calling the same meetings. A build like this helps only if the process around it changes too, which a teaching exercise cannot show.

More in Agents & automation
- The Forge Family: An Agent Operating System on Claude CodeMarketing and research command systems, desktop apps, and a study of AI brand governance.
- Google Ads Agent SystemOne command plans a Search campaign; a human always clicks Publish.
- Helm: A Marketing and E-Commerce Team in Software73 Claude-based roles with hard spending limits, and an honest review of what failed.