About the challenge
AI agents can search the web, write code, and call cloud APIs. What they cannot do reliably is control physical hardware. There is no standard way for an agent to discover a camera, reserve a sensor, actuate a motor, or read from a serial device. Every hardware integration is bespoke, brittle, and non-composable.
OAHL (Open Agent Hardware Layer) is an open protocol that changes this. It gives AI agents a uniform four-phase interface to any physical hardware: discover what is available, reserve a session, execute commands, and release. Hardware providers register their devices as typed capabilities. Agents consume them through a standard REST API without knowing anything about the underlying device, transport, or location.
This hackathon challenges builders to use OAHL to demonstrate real agent-to-hardware control. Build an adapter for a device that does not have one yet. Connect an AI agent to a piece of hardware and show what it can do. Push the protocol into a domain nobody has tried yet.
You do not need expensive equipment. A Raspberry Pi, an Arduino, a webcam, an Android phone, a soil sensor, a servo motor — any physical device you can connect is valid. The point is the integration, the intelligence layer, and the creativity of the use case.
Requirements
What to Build
Participants must build and demonstrate at least one of the following:
A new OAHL adapter that registers a previously unsupported hardware device as a typed capability in the OAHL registry. The adapter must implement the full four-phase lifecycle: discovery, reservation, execution, and release. It must return structured result envelopes conforming to the OAHL schema.
An agent-driven hardware demonstration where an AI agent (any model or framework) uses OAHL to control or read from a physical device to accomplish a meaningful task. The task should be something that would be difficult or impossible without the physical hardware connection.
Participants are encouraged but not required to combine both — a new adapter plus an agent that uses it to do something interesting.
Submission requirements
Your Devpost submission must include all three of the following or it will not be reviewed:
- Your code repository link with a README covering setup, hardware requirements, and how to run the adapter.
- Your approved registry URL from https://registry.oahl.dev — submit your adapter for approval before the submission deadline. Your listing must be live and publicly visible on the registry at time of judging. This URL takes the form https://registry.oahl.dev/adapters/your-adapter-name and confirms your adapter is correctly registered, discoverable, and passes the protocol requirements.
- A demo video of up to 30 minutes fully demonstrating what you have built in real time against real physical hardware. The video must show the complete agent-to-hardware flow: discovery, reservation, execution, and release. Narrate what is happening at each stage. Simulated or mocked hardware is not acceptable for the final submission video.
Prizes
First Place
Adapter featured prominently in the official OAHL capability registry and marketplace with the builder's name, description, and repository link. Dedicated blog post on the OAHL platform covering the build, the technical approach, and the builder's story. Social media spotlight across OAHL channels.
Second Place
Adapter included in the OAHL registry. Blog article covering the project. Social mention and acknowledgment in OAHL release notes.
Third Place
Adapter included in the OAHL registry. Builder credited in the OAHL contributors documentation.
All Valid Submissions
Every submission that correctly implements the OAHL protocol receives a contributor badge and is listed in the OAHL community adapters index regardless of placement. No submission that meets the technical bar goes unacknowledged.
Devpost Achievements
Submitting to this hackathon could earn you:
Judges
Frederick Abila
Buzz Chat
Judging Criteria
-
Hardware creativity
Does the submission connect a device type that has not been integrated before? Is the choice of hardware imaginative or unexpected? -
Protocol correctness
Does the adapter correctly implement the OAHL lifecycle? Does it return conformant result envelopes? Does it handle failure paths cleanly? -
Agent intelligence
How well does the AI agent reason about and utilise the hardware capability? Does it do something more than a simple script would? -
Real-world relevance
Does the use case address a genuine problem or opportunity? Could someone deploy this in a real setting? -
Documentation quality
Is the adapter documented well enough that another developer could use it? Is the README clear on setup, configuration, and capabilities?
Questions? Email the hackathon manager
Tell your friends
This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.
