AI Agents and Automation — When to Let a Model Take an Action

There is a habit of thinking that autonomy is earned by intelligence. Once the model is smart enough, the reasoning goes, we can let it off the leash. That framing quietly assumes the failure rate is the thing that matters. It is not. What matters is the product of two things: how often it is wrong, and what a single wrong instance costs you. A tool that is wrong one time in fifty is completely fine when the cost of being wrong is thirty seconds of your attention. The same tool is unusable when the cost of being wrong is a position you did not choose.

Sort every task the model might do by one question: can I undo it cheaply? Summarising an annual report is fully reversible. If the summary invents a figure, you read the page yourself and the summary is discarded. Drafting a note to yourself is reversible. Writing to a scratch file is reversible, because you can delete the file. Modifying your live watchlist is mildly irreversible — you can rebuild it, but you may not notice a name went missing for weeks. Sending an order is not reversible in any meaningful sense at all.

Notice that this ordering has nothing to do with difficulty. Summarising a three-hundred-page filing is a far harder task than sending a market order. The hard task is safe and the trivial task is dangerous, because danger lives in the consequence, not in the cognition. This is the single most useful reframe in the whole subject, and it is the reason experienced engineers are more conservative about agents than newcomers are, not less.

The other half of irreversibility is time. A wrong summary sits there quietly until you check it. A wrong order interacts with a live market immediately, at whatever liquidity exists in that instant. In a heavily traded NIFTY constituent, a mistaken order might cost you the spread and some brokerage. In a thin smallcap where the book is a few scattered bids, the same mistaken order can move the price against you on the way in and again on the way out. The instrument decides how expensive your mistake is, and the agent does not know which instrument is which unless you told it.

Autonomy is not a switch. It is a ladder, and almost all of the useful value sits on the bottom two rungs. Being explicit about which rung a given setup occupies is more valuable than any amount of debate about model quality, because the rung determines what can go wrong and therefore what you have to build to protect yourself.

The lowest rung is read-only work. The model reads something you gave it and produces text. It cannot touch anything. This is where filing summaries, concall extraction and watchlist triage live, and it is where the overwhelming majority of retail traders should stay indefinitely. Nothing on this rung can cost you money directly. It can only cost you money through you — by feeding you a wrong number that you then act on without checking, which is exactly what the audit-trail habit exists to prevent.

The second rung is drafting for a human to send or execute. The model prepares something — a research note, an order ticket with quantity and price filled in, a message — and a person reviews it and pushes the button. This preserves reversibility completely, because a human sits between intent and consequence. The catch is that this rung degrades over time. Review fatigue is real. After the fortieth correct draft, the forty-first gets a glance rather than a read, and that is when the wrong one goes through.

The third rung is a reversible action in a sandbox — a paper-trading account, a simulated broker, a test file. Real actions, fake consequences. This is the only honest way to learn how an agent behaves over hundreds of decisions, and it is the rung people skip because it feels like a waste of a month. The fourth rung is a real action gated by explicit confirmation, and the fifth is a real action taken unsupervised. Each of those last two rungs demands a strictly larger set of pre-built limits than the one below it.

The limits below are not optional polish that you add once the strategy is working. They are the price of admission to rungs four and five, and every one of them has to be built and verified before the first real action, not after the first bad one. The uncomfortable truth is that these controls are boring to build and offer nothing on a good day, which is exactly why they get postponed until the day they were needed.

A hard daily loss limit comes first: a rupee figure that, once breached, stops all new orders for the session and does not negotiate. It must be a number you decided while calm, written down before the session, and enforced by something other than your willpower at 2pm. Alongside it sits a maximum position cap — the largest quantity and largest exposure the system is permitted to hold in any single instrument, and in total. A cap is what turns a runaway loop from a catastrophe into an annoyance.

Then order rate limiting. A stuck loop can send the same order many times per second, and by the time you notice, the damage is done and the fills are yours. A rate limit — a hard ceiling on orders per minute, and a refusal to send the same instrument-side-quantity twice inside a short window — is trivially easy to implement and has saved more accounts than any clever signal ever has.

Two more, both about the world going wrong rather than the code going wrong. A heartbeat check: the system regularly proves to itself that it still has a working connection and current data, and if that proof fails, it flattens or refuses to open anything new rather than continuing to trade on a stale picture. And a kill switch you can reach from a phone, because problems do not wait until you are at your desk.

A chatbot makes one mistake at a time, and you see it. An agent makes a mistake in step two and then spends steps three through seven building confidently on top of it. This is the failure mode that is specific to agents, and it is genuinely different from ordinary model error, because each step in the chain treats the previous step’s output as established fact rather than as a claim to be checked.

Picture a plausible pipeline. Step one: pull the list of filings for your watchlist. Step two: match a company name in a headline to a ticker — and it picks the wrong one, because two listed companies have similar names and one of them is a small unrelated business. Step three: fetch fundamentals for that ticker. Step four: compare to the sector. Step five: score it. Step six: draft a note. Step seven: act on the note. Nowhere between two and seven does anything ask “is this the company we started with?” The output is fluent, internally consistent, and about the wrong company.

Small probabilities compound in an unfriendly direction. Even if each step is individually very reliable, a chain of many steps is meaningfully less reliable than any single step in it, and the reliability drops as the chain gets longer. This is why long, impressive agent demos are less trustworthy than short, boring ones, and why a five-step agent is not a slightly riskier version of a one-step agent — it is a different category of risk.

The defence is structural, not motivational. Make each step restate the key identifiers it received — ticker, exchange, period, document name — and check that restatement against what you originally supplied. Have the chain stop rather than guess whenever an identifier fails to match. And keep chains short: an agent that does one thing and hands back to you is far more defensible than one that does seven things and reports a conclusion.

A kill switch that has never been fired is a plan, not a control. The distinction matters because the situations in which you need it are exactly the situations in which everything else is already going wrong: your connection is flaky, your hands are unsteady, the market is moving, and you have perhaps thirty seconds of clear thinking available. Anything that requires you to remember a sequence of steps under those conditions will not work.

So the design constraints are unromantic. It should be reachable from a phone, because you will not always be at your desk. It should be a single obvious action, not a login followed by navigation followed by a confirmation dialog. It should halt new orders even if the agent process is wedged or looping, which means it cannot live entirely inside that process. And ideally it should be paired with whatever manual protections your broker platform itself offers, since those keep working when your own code does not.

The heartbeat is the other half. It answers a question the agent cannot answer for itself: am I still connected to reality? A regular check that the data feed is current and the session is alive, with a defined action when the check fails — stop opening anything new, and if positions are open and the rules say so, flatten. The failure this prevents is subtle and common: the connection drops, prices stop updating, and the system keeps making decisions against a frozen picture of the market that is now several candles out of date.

Then test it. Fire the kill switch on purpose, during market hours, with a position small enough that you do not care, and time how long it actually takes from decision to halted. Do it again after any change to the system. Simulate a dropped connection and watch what the heartbeat does. A control you have watched work once is worth more than five controls you have only written, and this is a lesson people almost always learn in the expensive order.

Automated order placement by retail participants in India is not an open field, and it is not something you should learn the rules of from an article. There is a SEBI framework governing algorithmic trading, and in practice it reaches you through your broker: the broker is the gatekeeper for API access, and there are approval and registration processes involved before a retail participant can run a strategy that places orders programmatically. Exchanges and the regulator care about who is accountable for an order and about controls at the system level.

That is the shape of it, and the shape is all this article will give you. The specifics — what needs approval, what does not, what your particular account permits, what has to be registered and by whom — change over time and vary by broker. Anyone telling you the exact current requirements in a blog post is telling you something that may already be out of date. This article does not state rule numbers, thresholds or fees for exactly that reason.

So the practical instruction is simple and it comes before any code. Ask your broker, in writing, what is permitted on your account: whether their API may be used to place orders automatically, what approval or registration is required, what the terms of use say, and what happens if a strategy misbehaves. Read what SEBI itself publishes at sebi.gov.in rather than a summary of it. If any part of your plan looks like it might cross from your own trading into acting for other people, stop and speak to a qualified professional before proceeding.

There is a second reason to have that conversation early, and it is entirely practical. The answer often changes the design. Some things you assumed you would automate may not be permitted on your account at all, and it is far cheaper to discover that before you have built a system around the assumption than after.

None of this means agents are useless. It means the value is concentrated on the bottom rungs, where the tooling is unglamorous and the payoff is real. The pattern that works is a read-only pipeline: something that gathers, extracts and presents, then stops and waits for you. It touches nothing that costs money, and it removes the part of your process that was pure clerical labour.

A concrete example. Each morning, fetch the exchange filings for the twenty names on your watchlist. For each filing, extract the type, the date, and three sentences of substance. Drop anything that is routine and procedural into a separate bucket. Write the result to a file with the source link beside each item, and ping you. Nothing in that chain can send an order. The worst outcome is a mis-summarised filing, and you catch that when you open the source link — which you do, because the link is right there.

The same shape works for concall processing, for turning your own trade log into a weekly review draft, and for the tedious first pass over a long document. In every case the agent’s job ends with a file and a notification. Yours begins there. That division is not a temporary limitation to be engineered away; it is what makes the arrangement defensible, and it is the same division that runs through the whole of this module.

If you eventually want more, earn it in the boring order. Spend real time on the sandbox rung with logs you actually read. Build the limits before you need them. Test the kill switch until firing it is muscle memory. And keep asking the only question that has ever mattered here: if this step is wrong, what does it cost me, and can I take it back?