AINEWS
The US Defense Advanced Research Projects Agency has put out a market survey for tiny, field reprogrammable devices that build and modify their own code on device, betting that throwaway electronics will matter more than data centers for austere, contested environments.
DARPA is asking industry and academia for a different kind of computer. The US Defense Advanced Research Projects Agency, the Pentagon's long-horizon research arm, posted a Request for Information on Friday on SAM.gov (opportunity id e7e66724a10f4bdc9e327c101347f71e) seeking "low-resource computing" paradigms for microscale systems that have not been used before, according to The Register's writeup of the solicitation.
The pitch is that computation is no longer the binding constraint. A chip-and-battery combo from a musical greeting card already carries more processing speed and memory than ENIAC did on its 80th anniversary, DARPA argues in the RFI, which makes the silicon itself almost free. What is not free is the physical and organizational scaffolding around it: power, packaging, foundry access, and the supply chain that has to keep producing the part.
That inversion is what DARPA calls a "resource paradox" at the low end of computing, and it is the real reason the agency is fishing for ideas rather than publishing a finished program. The Register's framing leans on the musical-greeting-card metaphor, which is DARPA's own, but the engineering target underneath is more specific: postage-stamp-sized devices that are cheap enough to be field-replaceable in spirit, that tolerate unreliable components, and that can be built with low-precision manufacturing or in "primitive technological ecosystems," DARPA's phrase for legacy fabs and supply chains that do not depend on the world's most advanced nodes.
The hardest part of the RFI is not the size or the price. It is "self-hosting." DARPA is not asking for devices that phone home for a software patch. It is asking for systems "capable of native, user-directed, autonomous self-programming and self-modification without reliance on external cross-compilation toolchains or host machines," with "architectures that allow the system to adapt, recompile, or generate its own operational code entirely on device." In other words, the chip would carry the compiler, the build system, and the rewrite logic inside its own package, and would be expected to update its own behavior in the field, on hardware that may itself be untrusted.
That combination, self-modifying code running on components from a low-trust supply chain, in austere environments where data sources and components may not be trustworthy, with minimum-necessary privilege and simple interfaces for non-specialist users, is the load-bearing ask. It is also the part that is hardest to secure. Code that rewrites itself on-device, on untrusted silicon, without a clean external toolchain to audit against, is a serious security problem, and DARPA is aware enough of that to call it out as a research question rather than pretending it is solved.
The Register's closing line projects that "even your average electronic greeting card might host a mini AI" if the program proves out. That is speculation, not a DARPA claim, and should be read as such. The RFI is a market survey, not a Broad Agency Announcement or a contract award, and the agency has not committed funding, a deadline, or a program structure to the responses yet. Industry and academic respondents are being asked to send back concepts, not proposals.
DARPA's broader track record as an incubator of technologies that did not exist before, from ARPANET to GPS to stealth aircraft, is the standing reason to take an odd-sounding solicitation seriously, and the agency maintains a public innovation timeline that doubles as a yardstick. It is also the reason to be careful. Some DARPA programs ship, some get archived, and the gap between a charming RFI and fielded hardware is measured in years and follow-on BAAs that have not been written yet.
What to watch next: whether DARPA turns the RFI responses into a BAA with funding attached, what "self-hosting" hardware prototypes look like in practice (FPGA-style programmable logic and on-chip code generation are the obvious mechanisms), and whether the security and supply-chain constraints end up shaping the program or quietly shrinking the addressable design space.