At Duolingo, anyone (engineer or not) can describe an internal tool and get a working app back, deployed against real company systems. That's BuildingHub, and 350 Duolingo employees have created at least one app with it. App generation is easy because we provide a set of connector APIs (Slack, Sheets, key-value storage, S3, Jira, employee data) plus a service proxy for everything else. All connectors are called through the same /api/... pattern, making them easily consumable by AI agents. I work on that contract layer directly by building and extending API connectors to support a growing set of internal use cases including prototypes, OKR trackers, live pricing tools, and event apps. 

What you'll leave with:

1. The shape of a connector API contract written for an AI agent as the primary reader and caller, and why we treat agent readability as a hard requirement.
2. Why "no new backend" is the rule that makes BuildingHub work: managed code lives at the API layer, user code stays at the client, and no app ever touches a secret.
3. How real usage reshaped the contract's design.
4. A tour of real BuildingHub apps and the connectors that power them.

If your company is buying an internal tools platform, this talk is the counterargument: agents can do the building if you invest in the right foundations. A connector API layer is a key piece of that investment, and I'll show why ours has been well worth it.