AlgoBuilder

1. Salesforce request
2. Cursor agent
3. BPWin flash QA
4. Hardware handoff
5. Code review

Engineers at BPM wrote each device-programming algorithm by hand: read the datasheet, work in BPWin with the chip in a socket, test on hardware, and submit the result for code review. Each algorithm took many engineering hours. Unattended runs also stalled on BPWin dialogs that the REST API could not see or dismiss.

• An orchestrator that pulls algorithm requests from Salesforce through MCP and runs a Cursor agent on each one through the algorithm-development workflow.
• Flash QA as a 19-test sign-off against BPWin, with persistent job state, retry and recovery, and a queue so only one request uses the physical programmer at a time.
• Google Chat messages that tell an engineer when a socket or chip needs to be swapped, and automatic code-review submission to a Mercurial branch once QA passes. A run refuses to start if credentials or the job ledger are missing.
• The BPWin REST API upgrade from 1.2 to 1.9 for unattended operation: job logs and status, remote dialog control, device and socket search, NAND ranges, live algorithm-database reindexing, and serialization checks. I wrote a 65-case test plan for it.
• Earlier in the internship, I rebuilt Chip, BPM’s internal AI assistant, around MCP, with Salesforce and Google Drive tools, tests, and lower model-call costs.

fully automated completion

80%+

validated algorithms

40+

estimated engineering time saved per algorithm

10–15 h

BPWin API test cases

65

Internal product. This page leaves out customer data, credentials, and algorithm source code.

• PDR Builder 2026