Ota
Software Execution Governance for Humans and AI Agents
Start new thread

For teams using AI agents in development: how do you tell the agent what is safe to run in a repo?

by•

AI agents are becoming part of everyday development, but most repos still don’t have a clear way to tell an agent what is safe to run, what needs to be checked first, or which commands are actually trusted.

That gap is what we’re thinking about with Ota: making repo execution knowledge explicit enough for humans, CI, and AI agents to follow without guessing.

Curious how other teams are handling this today.

65 views

Add a comment

Replies

Best
Hi Adamma — this really resonates. I build my app (NEXIA, an AI app) almost entirely with an AI coding agent, so "how do you tell the agent what's safe to run" isn't theoretical for me — it's a daily safety question What's worked for me is treating a few documents as the single source of truth for execution knowledge: a top-level file (plus a docs/ folder) that explicitly states what's frozen, what's forbidden, and what must be checked before running anything. The agent reads it before acting. That's basically what you're describing with Ota — making the "what's safe" knowledge explicit instead of letting the agent guess. But here's the lesson I learned the hard way: documentation alone isn't enough. I now think of it as three levels of protection, from weakest to strongest: Docs only — "don't touch X." Depends on the agent actually reading and respecting it. Fragile. Automated tests — a test that fails if a protected behavior changes. Catches regressions even when the doc is missed. Hard/platform locks — read-only production database, locked config files. The mistake becomes impossible. A real example: a plan to modify a deliberately frozen part of my codebase got proposed mid-session. It was refused only because the freeze was written explicitly in my source-of-truth doc. Without that, the agent would have happily done unsafe work. That's exactly the gap you're pointing at — and it's what convinced me that for the few truly catastrophic operations (production data, deployments, frozen modules), docs aren't enough on their own; I back them with a test or a hard lock. So my short answer: make the knowledge explicit in one canonical place the agent always reads — but for the handful of operations that could cause real damage, enforce it with something that can't be ignored, not just described. Curious to see where Ota lands on that doc-vs-enforcement spectrum.

 Fotso, this is such a thoughtful breakdown, and the three-level framing (docs → tests → hard locks) is exactly the kind of mental model we wish more teams were working with. The real-world example with NEXIA really drives it home: the freeze held because it was explicit, not because the agent was smart enough to figure it out on its own.

You've named something important: docs are the starting point, but they're only as strong as the agent's willingness to read and respect them in the moment. Context windows get long, sessions get messy, and that's when implicit knowledge fails you.

On where Ota lands on that spectrum, we're building toward the enforcement end, not just the documentation end. The goal is that your execution rules aren't just described in a file somewhere, but actually structured in a way that's verifiable by CI, by the agent, and by your team. Think of it as giving the "what's safe" layer real teeth, not just good intentions.

Would love to stay in touch as you keep building NEXIA. The patterns you're discovering in daily use are exactly the kind of feedback that shapes where we take this. 🙏

Thank you, Adamma, that really means a lot. To be honest about where I'm coming from: I'm an electrician by trade, with no background in development. I built NEXIA entirely with Replit Agent, and it was a genuine challenge for me from start to finish. In a few numbers, what NEXIA took: ~10,900 lines of system prompt across 15 dedicated doctrines ~83,800 lines of code 50+ bugs and hallucinations caught and fixed 67 audit cycles 59 automated test & security suites put in place I built it in 2 months. The beta launches on June 17, and user feedback will be hugely important to me for the last round of fixes. I'm not sure yet whether Ota can help during this specific phase — but I'd happily share the bug log, the tests, the audits and the testing protocols we put in place while building NEXIA, if that's useful to you. What I'm fairly sure of is the next step: I'm planning an expert version of NEXIA with advanced capabilities — more engines, more prompt doctrines, more complexity overall. That's the phase where I think I'll genuinely need something like Ota. So I'd love to understand it better: how does Ota actually work, can it integrate with Replit, or at least how would I go about using it? 🙏

 What you built from a totally different background is seriously impressive! I'll be sure to support on the 17th.

On Ota: it is a repo execution contract that lives in your repo as `ota.yaml`. You can use it on Replit like any other CLI tool. The point is to stop the agent guessing. Ota defines what the repo needs, what tasks exist, what is safe to run, and what should be verified after changes.

In practice:

`ota doctor` shows what is missing or risky

`ota up` prepares the repo correctly

`ota tasks` shows the approved runnable surface

`ota run ` runs named tasks through the contract instead of freehand shell guesses

We do not have a native Replit integration today, but because Ota is repo- and CLI-based, it can still work there if Replit Agent can read repo files and run shell commands.

Best way to start:

install Ota:

run `ota detect --contract` or `ota init --dry-run`

keep only the real setup/run/verify paths

run `ota doctor`

Happy to help you all the way. If you want, send me your stack and I can point you to the closest example to start from:

If useful, you can also install the Ota skill so your AI agent can help you shape a solid `ota.yaml`: `npx skills add ota-run/skills --full-depth`

  

Small practical note from the agent-builder side: before a tool like Ota or anything similar, I would separate three things.

What the agent knows.
What the agent is allowed to do.
What proof gets saved after it acts.

Your bug logs and audit cycles are actually useful raw material for that last part.

   Yes, that is a very good framing, and it lines up well with Ota.

Ota is designed to make those three things explicit:

- what the agent knows:

the repo contract in `ota.yaml` defines setup, tasks, requirements, checks, workflows, services, and execution truth

- what the agent is allowed to do:

Ota can define safe tasks, writable paths, protected paths, and what must be verified after changes

- what proof gets saved after it acts:

Ota can emit receipts and JSON output so execution is not just "the agent said it ran something," but a structured record of what was run and what happened

The honest nuance is that Ota is strongest today on the first two, and getting stronger on the third. So if you mean full long-term audit history, bug ledgers, or review archives, that is adjacent to Ota. But if you mean "can the repo contract define execution truth, boundaries, and produce structured evidence after action," then yes, that is very much where Ota is headed.

If you want to see a real pressure-tested contract, Open WebUI is a good one because it is an AI app repo rather than a toy example.

Thank you, Ahmad, this is genuinely helpful. Separating "what the agent knows / what it's allowed to do / what proof gets saved after it acts" is a much cleaner way to think about it than I had — I was lumping all three together. And good to know my bug logs and audit cycles already feed that last layer. Really appreciate you taking the time. 🙏

We started wit but it gets outdated pretty quickly. The bigger challenge is keeping rules in sync with how the repo actually evolves

 This is one of the most common things we hear Furkan, and honestly it's what pushed us to think beyond just a file format. is a great starting point but a file that lives separately from your actual execution context will always drift. The rules and the repo end up telling different stories over time.

With Ota, the goal is for your execution contract to stay grounded in what the repo actually does, not just what someone documented at setup. So as the repo evolves, the governance evolves with it rather than falling behind. Would love to hear more about where the sync breaks down for your team specifically.

This is the part I would want outside the prose file: a small contract that can fail when repo behavior drifts. Otherwise AGENTS.md becomes a policy doc with no test attached.

The cleanest pattern I have seen is three layers:

1. Describe intent in repo docs.

2. Enforce dangerous actions outside the model.

3. Keep a receipt after the action runs.

Docs help the agent behave. Enforcement is what saves you when the context gets messy.

 You're right Ahmad, and that third point about keeping a receipt is underrated! Most of the conversation around agent safety stops at "how do we prevent bad actions" but auditability matters just as much. When something does go wrong, knowing exactly what ran, when, and why is what lets you recover and improve.

The framing of enforcement living outside the model is also key. You can't rely on the model to police itself, especially when context gets long or instructions get buried. The guardrails need to exist at a layer the model can't talk its way around.

This is very much the thinking behind Ota. Receipts are actually a first-class concept in how Ota works, archiving execution state so teams can check for drift and trace what actually ran against what was approved. Appreciate you putting it so cleanly.

  yes, exactly. The receipt is where the product stops being a nice guardrail and starts becoming operational infrastructure.

This is also the angle I am taking with Weavz: outside-the-model enforcement for SaaS actions, scoped credentials, approvals, state/files, and receipts for what actually happened.

Different surface than Ota, same scar tissue: agents need a boring layer they cannot argue with.