“You can just build things” is true in principle but not in practice. The gap between an idea and a working app has never been smaller, while the gap between a working app and one built properly keeps growing.
At Reducto, we’re a highly agent-enabled team. If someone across any of our orgs wants to build a new app, dashboard, or tool, they can easily get the tokens to do so. Then the real questions start:
- Where does this app run? Does it need a database or persistent volumes?
- Who is allowed to open it? Does that include someone outside the company?
- It needs API keys. Where do those go, and are there any security issues?
- Who deployed this version? What happens if it breaks? What if their agent made a mistake?
An agent can write the code, but it can’t come up with good answers to those questions on its own. And for a lot of our team, the overhead of answering those questions comes with asking for tools, having excessive permissions, or extra seats on critical systems as we scale.
But those limitations come with velocity tradeoffs. Our team has to stop building, exercising their creativity, and going above and beyond for our customers because there are too many open questions.
We wanted to enable our team to build with agents the right way, and that meant owning the entire lifecycle, so our agents know the details and our team trusts the agents.
Building a zero-trust platform
We wanted our platform to be built around a few core principles:
- Identity and Access Management: Every visitor should sign in through one system using our existing auth. Each app should decide who’s allowed to see it and enforce that on every route for that app.
- Secrets: Secrets should never be leaked to a browser or stored in plain text, and they should be easy to manage.
- Provenance: Every change and deployment should be tracked to the user or agent, and auth success and failure should be tracked to the visitor.
- Reliability: Apps should allow deletion and changes should allow rollback. All these apps should live entirely outside of our customer-facing infrastructure to not cause confusion.
These are all things agents can easily overlook, so we built them into the code instead of relying on prompts and reasoning to get them right.
Identity and Access
The first piece is Reducto Access, a Cloudflare Worker that proxies the routes that our apps live on through an internal zone (for dashboards and internal tools) and an external zone (to present to our customers).
Whenever a request comes in on that zone, the worker redirects users to sign-in, verifies sessions and access policies, and passes trusted identity headers that the app can use downstream. When our internal agents, such as Devin, try to access the app through their browsers, we can use their existing OIDC systems to show who started the session and link their user information.
Because of this, our apps don’t have to build login pages or access policies, and can still see user details to provide personalized experiences.
Infrastructure and Deployment
Since we first started with Access, we quickly saw the benefits of this internal network, but also the limitations. Apps were deployed across different cloud providers with the exact location and creator of the code unknown, and our teammates not on engineering weren’t sure what best practices were.
We’ve since replaced all these pieces with Reducto Hosting. With Hosting, a user (or their agent) can now push to our internal Git server, and have apps stored, built, and served on domains of their choice automatically behind our Access gate.
Through a combination of Cloudflare tools, such as using R2 and Containers for a walgit-backed server similar to Origin as well as hosting static and server sites, Workflows for automatic CI, and D1 for metadata storage, we’re able to serve a variety of apps from HTML pages to Node and Python servers that host dashboards calling our databases or APIs (we even added different server sizes for more demanding projects).
When we want to serve a richer experience, we use R2 FUSE to mount “disks” to our servers, which is great for displaying documents or storing richer data such as for data labelling. Apps can also opt into a SQLite database backed by Durable Objects in case they need their own downstream metadata storage, such as for providing custom experiences.
Within our hosting platform, the following safeguards are consistently in place:
- Secrets are write-only and encrypted at rest between build and run time. Static apps never get secrets at all.
- Deploys wait for everything they need:
- Before any new builds go live, we run health checks and keep the previous version until we’re sure things will run. If secrets are missing, we notify on the dashboard until they’re set.
And by using a Git server, we can track changes, build logs, the access configuration, and roll back immediately when needed, but it also makes for a collaborative experience. As these apps are experiments for the team, anyone can contribute through branches, deploying from a specific commit, and sharing the platform without worrying about seats, access controls, or taking down prod.
Building for (and with) agents
All of this was to get us to a trusted platform and boundary, but the day-to-day work is done by agents. Every action that a user can take through the UI can be done through a custom CLI or API requests that also serve documentation endpoints if someone is trying a new agent.
Every action the agent takes, whether it’s logging into an app or pushing to Git, also records both the agent session and the person it’s acting for, and when tasks finish, the agents are given all the information to report the app’s state back to the user, and ask for more information if needed.
What we’ve unlocked
Once we unlocked this path and showed it to the team, we’ve helped foster a culture of building across everyone at Reducto. Rather than engineering dashboards, we’ve seen previews built on sample documents for prospects, viewers made to show our best-in-class accuracy and latency metrics, and internal tools to help drive growth and customer success that wouldn’t have been a project on their own.
Most of these start as a Slack message to agents, where the user describes what they need with any supporting information, the agent builds and deploys the app, and the person gets back a URL with the right access settings already in place.
Since rolling this system out two months ago, we’ve had nearly 200 apps deployed and 100% usage across the team, with 30% of these apps received by customers, with all these numbers growing week over week.
By building the right infrastructure layer to enable our team, we’ve helped reach a new velocity of work between our team and their agents.
If you want to build tools that build tools, we’re hiring: reducto.ai/careers