DEV Community: Alon Trifonov

I Planned a Multi-Agent Coding System. Here Are the 7 Decisions That Matter

Alon Trifonov — Thu, 29 Oct 2026 14:44:58 +0000

At Zyntari, my engineering studio in Israel, I am building a system where multiple AI coding agents work on real software projects: taking tasks, writing code, running tests, opening pull requests, and waiting for approvals. Before writing code, I wrote a full technical specification with every architecture decision, every tradeoff, and every thing we deliberately will not build.

A spec is usually private. But the decisions in it apply to anyone trying to run more than one coding agent on anything real, so here are the seven that matter most, why we made them, and how to steal them.

The short version of the whole philosophy: agents are allowed to reason, but they are not allowed to decide what is true. The system owns the truth. That single rule drives almost everything below.

Decision 1: A state machine runs the show, not a conversation

Most agent systems today are a chat that remembers things. The agent narrates what it is doing, and whatever it says becomes the state of the project. That works until the agent gets confused, contradicts itself, or the process dies mid-sentence.

Our rule: task state lives in PostgreSQL, and agents can only request state changes. A task moves through explicit states (proposed, planned, running, awaiting_review, merging, completed), and transitions happen through one pure function that either returns the new state with the events it emits, or returns a rejection.

No caller, human or agent, updates state directly in the database.

An agent finishing its work does not get to say "done." It must return structured output validated against a schema:

const AgentResultSchema = z.object({
  status: z.enum(["completed", "blocked", "failed", "needs_review"]),
  summary: z.string().max(4000),
  commitSha: z.string().regex(/^[0-9a-f]{40}$/).optional(),
  changedFiles: z.array(z.string()).max(500),
  acceptanceCriteria: z.array(z.object({
    id: z.string(),
    status: z.enum(["passed", "failed", "not_tested"]),
    evidenceRefs: z.array(z.string()),
  })),
});

The important line is the design rule behind it: a model saying status: "completed" is not a verdict. It is a request to be verified. Tests, reviews, and evidence decide completion. Prose never can.

Decision 2: Temporal owns durability, and determinism is non-negotiable

An agent run is not a web request. It can take twenty minutes, wait two days for a human approval, and survive a crashed server. You can hand-roll that, or you can use a workflow engine built for exactly this. We chose Temporal, and Temporal's own documentation describes the same shape we use: the agent loop is a Workflow, each model call and tool call is an Activity, and a crash resumes the conversation instead of restarting it.

That architecture comes with one strict rule, and it is the rule people break first: workflow code must be deterministic, because Temporal replays it from history after failures. So no LLM calls, database queries, Git commands, or random IDs inside workflow code.

All side effects live in Activities, which are recorded once and replayed from history. The moment you put a direct API call inside a workflow, recovery stops working and you will not notice until the first crash.

For long agent runs, Activities heartbeat their progress: which session is running, which phase it is in, and how much it has spent so far. A heartbeat timeout is how you learn that a Claude process or a whole host died, instead of finding out from a silent dashboard.

Decision 3: Drive agents with an SDK, not terminal keystrokes

The obvious way to automate a coding agent is to run it in a terminal and script the keystrokes. It is also a dead end: no structured events, no reliable cost data, no way to resume a session after a crash.

The Claude Agent SDK exposes the same agent loop that powers Claude Code programmatically, in TypeScript and Python: messages, session IDs, tool permissions, hooks, budget limits, and structured output.

Every run records its session ID before it is allowed to touch anything, so a crashed run can be resumed instead of restarted. Hooks let us enforce policy in the host process before any tool executes, which matters because a policy check does not consume model context and cannot be talked out of by a prompt.

One detail worth copying even in small projects: model recommendations in tool metadata, things like "this tool is read-only," are hints for scheduling and display, not security controls. Enforce permissions yourself, in code, before execution.

Decision 4: One Git worktree per task, and a sandbox around the worker

Two agents should never share a writable checkout. Every implementation task gets its own Git worktree, and the system enforces a conservative write set: the paths the task owns, plus the files those paths implicate, like lockfiles and shared configuration. Tasks with overlapping write sets do not run at the same time. Lockfile changes and database migrations take a repository-wide lock, because those are the changes that break everyone else's in-flight work.

Around the worker process, a boring security profile on Linux: rootless Docker, non-root user, write access only to its own worktree, no Docker socket, a default-deny network with an allowlist for exactly the endpoints it needs, and a default seccomp profile that is never disabled for convenience. Nothing here is exotic.

It is the same discipline you would apply to any process that executes machine-generated code, which is what an agent is.

Decision 5: The scheduler is an algorithm, not a mood

When you have many tasks and a few agents, someone has to decide what runs next. The tempting 2026 answer is "let an agent decide." Ours does not.

The task graph is validated deterministically: every dependency exists, no cycles (Kahn's algorithm, cheap and absolute), every objective maps to an acceptance criterion. Priority is a weighted formula combining business priority, critical path, wait age, and expected cost. Agents may classify inputs, like labeling a task as security-sensitive, but those classifications are constrained enums with a confidence score.

The final number comes from the formula.

Why so rigid? Because a scheduler that is a formula can be tested, logged, and debugged. A scheduler that is an LLM judgment call cannot answer the question "why didn't my urgent task run" without another LLM judgment call.

Decision 6: Classify failures before you retry anything

Blind retry is how a small problem becomes a large bill. We classify every failure first, and each class gets a different response:

Failure class	Example	Response
Transient	network reset, provider 5xx	Retry with backoff and jitter
Rate limit	quota hit	Wait until the supplied reset time
Worker loss	crashed process	Resume the session, or start a clean attempt
Validation	malformed output	One repair attempt, then fail
Deterministic	reproducible compile error	Send back for replanning
Policy violation	forbidden command	Never retry. Escalate
Budget reached	cost ceiling hit	Pause and ask for a decision

Backoff is exponential with full jitter, and automatic retries stop at two. If three attempts failed, the task definition is the problem, not luck.

Decision 7: Budgets and fencing tokens, because agents are processes that spend money

Every run reserves predicted cost from its parent budgets before it starts, and reconciles actual cost when it ends. Circuit breakers pause automatic spawning when a project reaches 80% of daily budget, when an attempt costs twice its prediction, or when token burn rate spikes.

I wrote about this pattern for regular applications in a previous article about spending limits; in a multi-agent system it stops being a best practice and becomes load-bearing, because the system can spend money while you sleep by design.

And one classic distributed-systems lesson that agent systems rediscover the hard way: fencing tokens. Every lease on a task or worktree carries a number that only goes up. If a worker's lease expires and the task is handed to someone else, late results from the old worker are rejected even if it wakes up and politely reports success.

Without this, two workers eventually write to the same place, and they will do it while everything looks healthy.

What we deliberately did not build

The spec has a longer section on non-goals than on most features: no Kubernetes, no Kafka, no Redis, no vector database, no learned routing model in version one, and no agents sharing a writable checkout. Temporal already provides durable queues, timers, and retries. PostgreSQL provides transactional state.

Every additional component is a bottleneck you have not measured yet, dressed as preparation.

The same discipline applies to agent memory: versioned Markdown files with PostgreSQL full-text indexes, not an embeddings stack, until keyword retrieval demonstrably fails. Code memory is dominated by exact symbols, paths, and commands, where lexical search usually beats semantic similarity anyway.

How to steal this

If you are building anything in this space, the order matters more than the parts. Build the deterministic skeleton first, state machines and event logs, and prove that killing every process neither loses nor duplicates a task. Then add the agent runtime. Then the operator surface. Only after one real bug travels from intake to a protected-branch merge with zero manual copying do you earn a second department of agents.

Agents reason. The system decides. That is the entire architecture in one sentence.

Alon Trifonov is the founder of Zyntari (zyntari.com), an independent engineering studio in Israel that builds production-grade software and AI systems. He works in Python, TypeScript, and everything that has to keep running after the demo ends. LinkedIn Github

Nobody Prompts for a Spending Limit: How to Stop Your AI App From Burning Money Overnight

Alon Trifonov — Wed, 28 Oct 2026 12:51:40 +0000

A client of mine once left an automated AI app running unsupervised for one day. The app generated websites end to end: every job triggered AI calls, the AI calls triggered more jobs, and nothing anywhere in the system capped how many could run at once, how much the app was allowed to spend, or how to make it stop.

One day later: an AI bill of over $1,000. The app worked exactly as built. Nobody had built the brakes.

I'm Alon Trifonov, founder of Zyntari, a small engineering studio in Israel. I take AI-generated prototypes and turn them into production software, and this story is the quiet failure I see most often. Not a hack, not a bug that crashes anything. Just an app doing its job with no limit on what that job costs.

The industry is waking up to the same problem. Gartner predicts over 40% of agentic AI projects will be canceled by the end of 2027, citing escalating costs and inadequate risk controls. And in September 2026 they added a newer, sharper warning: by 2030, 80% of organizations with public-facing AI will experience a "cost exhaustion attack", where someone deliberately drives up your AI usage to inflate your bill. So this is not only about your own code looping. Strangers can burn your budget on purpose, through the public features you shipped.

Here is how to build the brakes, in five layers, with code. Everything below is Python and Flask flavored, but the patterns work in any stack.

Layer 1: Set the hard limit at your provider (do this today)

This takes five minutes, requires zero code, and is the single highest-value step in this article.

OpenAI supports monthly spend limits at both the organization and project level. Go to your organization settings, open Limits, set a monthly spend limit, and this is the important part: turn on "Enforce a hard limit." Without that toggle, the limit only sends you alerts while requests keep flowing. With it, API calls start failing when you hit the number, which is exactly what you want at 3am. Anthropic offers the same idea for Claude, with organization and workspace limits in the Console.

Set the number to what you can actually afford to lose in a bad month. Not what you expect to spend. What you can afford.

One warning: provider limits are your last line of defense, not your only one. They reset monthly, they apply to everything under the project, and when they trip, your feature just dies. You want your own code to slow down and stop gracefully long before the provider pulls the plug. That is what the next layers are for.

Layer 2: Know what every call costs

You cannot cap what you do not measure. Most generated code treats an AI call as free: send prompt, get answer, move on. The fix is a small pricing table and a cost log on every single call.

MODEL_PRICES = {
    "gpt-4o-mini": {"input": 15, "output": 60},
    "gpt-4o": {"input": 250, "output": 1000},
    "claude-sonnet-4-5": {"input": 300, "output": 1500},
}
# prices per 1M tokens, in USD cents.
# Check your provider's pricing page and keep this current.

def call_cost_cents(model: str, usage) -> int:
    prices = MODEL_PRICES[model]
    input_cost = (usage.prompt_tokens / 1_000_000) * prices["input"]
    output_cost = (usage.completion_tokens / 1_000_000) * prices["output"]
    return round(input_cost + output_cost)

Every API response already carries the token counts in response.usage. Wrap your AI calls so each one logs the model, the tokens, and the cost in cents to a table:

class AIUsage(db.Model):
    id = db.Column(db.Integer, primary_key=True)
    created_at = db.Column(db.DateTime, default=datetime.utcnow, index=True)
    model = db.Column(db.String(64))
    feature = db.Column(db.String(64))
    cost_cents = db.Column(db.Integer)

The feature column matters more than it looks. When the bill jumps, this is how you answer "which part of my app spent it" in one query instead of one week.

Layer 3: A budget check before every call

Now the actual brake: before any AI call, ask "are we allowed to spend this today?"

DAILY_BUDGET_CENTS = int(os.environ.get("AI_DAILY_BUDGET_CENTS", "2000"))  # $20

class BudgetExceeded(Exception):
    pass

def check_daily_budget():
    today = datetime.utcnow().date()
    spent = (
        db.session.query(func.coalesce(func.sum(AIUsage.cost_cents), 0))
        .filter(func.date(AIUsage.created_at) == today)
        .scalar()
    )
    if spent >= DAILY_BUDGET_CENTS:
        raise BudgetExceeded(f"Daily AI budget reached: {spent} cents")

Then wrap every AI call in one function that checks before and records after:

def guarded_ai_call(feature: str, model: str, messages: list):
    check_daily_budget()
    response = client.chat.completions.create(model=model, messages=messages)
    cost = call_cost_cents(model, response.usage)
    db.session.add(AIUsage(model=model, feature=feature, cost_cents=cost))
    db.session.commit()
    return response

In your routes, catch BudgetExceeded and return something graceful: a "this feature is paused until tomorrow" message beats a crashed page and beats a surprise invoice. Every AI call in the app goes through this one wrapper. No exceptions, no "just this once" direct calls in a controller somewhere.

Layer 4: Cap concurrency and retries

This is the layer that would have saved my client their $1,000 day. Their app had no limit on how many jobs could run at the same time, so one busy morning multiplied itself.

Two knobs handle most of it.

First, worker concurrency. If you run background jobs with Celery, the worker flag is the cap:

celery -A app.celery worker --concurrency=4

Four workers means at most four AI jobs burn money at the same moment. Set it from your budget, not from your CPU count.

Second, retry discipline. Retry logic is where quiet bills hide, because a retrying loop is an AI call inside a loop. If you use tenacity, cap it hard:

from tenacity import retry, stop_after_attempt, wait_exponential

@retry(stop=stop_after_attempt(3), wait=wait_exponential(min=2, max=30))
def call_model(messages):
    return guarded_ai_call(feature="site-builder", model="gpt-4o", messages=messages)

Three attempts with exponential backoff. Never retry_forever on anything that costs money per attempt. If it failed three times, the fourth try is not your biggest problem anymore.

Layer 5: A kill switch you can hit from your phone

Budgets slow the bleeding. Sometimes you need to stop it completely, fast, without a deploy. Add a switch that every AI feature respects:

def ai_enabled() -> bool:
    return os.environ.get("AI_FEATURES_ENABLED", "true").lower() == "true"

# inside guarded_ai_call, before anything else:
    if not ai_enabled():
        raise RuntimeError("AI features are disabled")

Now stopping every AI feature in your product is one environment variable change on your host, which takes thirty seconds from the Render or Railway dashboard on your phone. Pair it with an alert before you need it: when daily spend crosses 80% of budget, send yourself a message. A Slack webhook or even a plain email works. The alert is what turns "one unsupervised day" into "one weird hour I caught at lunch."

The checklist

Run this against any app that calls an AI model:

Hard spend limit set at the provider, enforced, not just alerting
Every AI call logged with model, feature, and cost in cents
A daily budget check that refuses calls before they happen
Worker concurrency capped, retries capped at three
A kill switch you can flip without deploying
An alert at 80% of budget, so you hear about problems the same hour

None of this is exotic engineering. It is an afternoon of work. But it is also invisible, and invisible work is exactly what AI builders skip, because nobody types "and please add a spending limit" into a prompt box. The model builds what you ask for. The brakes are on you.

If you want the bigger picture around this, I wrote an honest guide to what building an app with AI actually involves in 2026, including where the demo ends and the real work starts. And if your app also needs its security holes closed, that checklist is in my previous article.

Alon Trifonov is the founder of Zyntari (zyntari.com), an independent engineering studio in Israel that turns prototypes and AI-generated apps into secure, production-grade software. He builds with Python, Flask, and React, with security and reliability as defaults rather than afterthoughts. LinkedIn: https://www.linkedin.com/in/alon-trifonov-546061234/

5 Security Holes Almost Every AI Generated App Ships With (And How to Fix Them)

Alon Trifonov — Tue, 27 Oct 2026 11:40:13 +0000

AI app builders like Lovable, Bolt, and v0 are impressive. You describe what you want, wait a few minutes, and get a working app that looks ready for real users.

It is not ready for real users.

I'm Alon Trifonov, founder of Zyntari, a small engineering studio in Israel. A big part of my job is taking AI-generated prototypes and turning them into production software, mostly Python and Flask on the backend. After auditing a bunch of these apps, I keep finding the same five security holes. Not exotic, movie-hacker stuff. The boring classics: the kind that show up in the OWASP Top 10 year after year because developers keep making the same mistakes. Now AI generators are making those same mistakes at scale.

Every one of them is fixable in under an hour. Here is what to look for, how to check if your app has the problem, and exactly how to fix it.

1. Debug mode left on

Open the main file of your generated app. If you see this, you have a problem:

if __name__ == "__main__":
    app.run(debug=True)

Why it's dangerous: debug=True enables the Werkzeug debugger, an interactive Python console that runs in your browser. If it ever reaches a live server, anyone who triggers an error in your app gets a console that can run arbitrary code on your machine. The Werkzeug documentation says it in plain words: "the debugger must never be used on production machines."

This is not a theoretical risk. In 2015, Patreon, a company with millions of users, left the Werkzeug debugger publicly accessible. Security researchers at Detectify warned them about it, and days later attackers walked in through exactly that hole and dumped 15 gigabytes of user data online, including 2.3 million email addresses.

How to check: search your whole codebase for "debug". Every match should end up controlled by the environment, never hardcoded.

The fix:

import os

if __name__ == "__main__":
    app.run(debug=os.environ.get("FLASK_DEBUG", "false").lower() == "true")

And in production, don't use Flask's built-in server at all. Use Gunicorn:

gunicorn -w 4 -b 0.0.0.0:8000 "app:create_app()"

2. Secrets sitting directly in the code

Generated code loves this pattern:

app.secret_key = "super-secret-key-123"
STRIPE_API_KEY = "sk_live_..."

Why it's dangerous: anything committed to a Git repository should be treated as public. Yes, even in a private repo, because repos get shared, cloned, screenshotted, and pushed by accident. GitGuardian scans every public commit on GitHub, and their State of Secrets Sprawl 2026 report found 28.65 million new hardcoded secrets pushed to public GitHub in 2025 alone, up 34% year over year. Worse for us specifically: AI-assisted commits leaked secrets at roughly double the baseline rate.

How to check:

grep -rInE "(secret|api[_-]?key|password|token)\s*=\s*[\"']" . --include="*.py"

If that command prints anything that looks like a real value, that is your to-do list.

The fix: secrets come from the environment, never from source code:

import os

app.secret_key = os.environ.get("SECRET_KEY")
if not app.secret_key:
    raise RuntimeError("SECRET_KEY is not set. Refusing to start insecurely.")

Generate a proper key:

python -c "import secrets; print(secrets.token_hex(32))"

Then set it wherever you deploy. Render, Railway, and Docker all have an environment variables section for exactly this. And if a secret already leaked: rotate it. Deleting the commit does nothing. The value already lives in the repo history and in every scanner's database.

3. SQL injection hiding in "dynamic" queries

Generators usually do the right thing and use an ORM like SQLAlchemy. The trouble starts when the AI needs something "dynamic," like a search filter, and reaches for string formatting:

email = request.args.get("email")
query = f"SELECT * FROM users WHERE email = '{email}'"
result = db.session.execute(query)

Why it's dangerous: that f-string is a door directly into your database. A user who types ' OR '1'='1' -- as their email just bypassed your login. Injection has been in the top three of the OWASP Top 10 for over two decades, precisely because one formatted string is all it takes.

How to check: search for f", %, or .format( on the same line as execute(. Any hit is a red flag.

The fix: pass values as parameters and let the driver escape them:

from sqlalchemy import text

email = request.args.get("email", "")
result = db.session.execute(
    text("SELECT * FROM users WHERE email = :email"),
    {"email": email},
)

Or stay fully in the ORM, which is even simpler:

user = User.query.filter_by(email=email).first()

Rule of thumb: if you ever see an f-string inside a database query in AI-generated code, review the entire file. Where there is one, there are usually more.

4. Login endpoints anyone can hammer forever

A typical generated login route looks fine:

@app.route("/api/login", methods=["POST"])
def login():
    user = User.query.filter_by(email=request.json["email"]).first()
    if user and check_password(request.json["password"], user.password_hash):
        return jsonify(token=create_token(user))
    return jsonify(error="invalid credentials"), 401

The problem is what it doesn't do: it lets anyone try passwords as fast as their machine can send requests. No limit, no slowdown, no lockout. Weak passwords fall in hours.

How to check: look at your login endpoint and ask a simple question. What stops someone from sending ten thousand requests? If the answer is "nothing," that is the hole.

The fix: rate limit the sensitive endpoints. Flask-Limiter makes it a two-line change:

from flask_limiter import Limiter
from flask_limiter.util import get_remote_address

limiter = Limiter(get_remote_address, app=app, storage_uri="redis://localhost:6379")

@app.route("/api/login", methods=["POST"])
@limiter.limit("5 per minute")
def login():
    ...

Five attempts per minute per IP turns "try a million passwords tonight" into "try a few thousand over days." Most attackers just move on. Do the same for registration, password reset, and any endpoint that sends emails or SMS. Those are abuse magnets too. And make sure passwords are stored with bcrypt or argon2, via Werkzeug's generate_password_hash, never plain text or fast hashes like MD5.

5. No security headers at all

Open your browser's developer tools, go to the Network tab, and click any response from your app. If you don't see headers like Content-Security-Policy or Strict-Transport-Security, your app is telling browsers "trust everything, embed me anywhere."

Why it's dangerous: without a Content-Security-Policy, one reflected XSS, meaning a malicious script sneaked in through user input or a crafted link, runs with full access to your users' sessions. Without X-Frame-Options, an attacker can embed your app inside their own page and trick users into clicking things they can't see. That is clickjacking. Flask deliberately does not set these headers for you, and generators quietly skip the step.

The fix: one extension, about ten lines:

from flask_talisman import Talisman

Talisman(
    app,
    content_security_policy={
        "default-src": "'self'",
        "script-src": "'self'",
        "style-src": "'self'",
    },
    force_https=False,  # let your reverse proxy (Nginx/Cloudflare) handle HTTPS
)

If your app legitimately needs external scripts like analytics or payment widgets, add those specific domains to the policy instead of disabling it.

The bigger picture

None of this is really the AI's fault. Generators optimize for "does it run and does it look right." Security is invisible until the day it fails, so it gets skipped by default. Every generated app needs one deliberate hardening pass before real users and real data touch it. One hour, one checklist:

No debug=True anywhere near production
No secrets in code. Environment variables only, and rotate anything that ever leaked
No f-strings or string formatting inside database queries
Rate limits on login, registration, and reset endpoints
Security headers via Flask-Talisman
Bonus: passwords hashed with bcrypt or argon2, and dependencies scanned regularly

My rule of thumb, and the mindset behind everything we ship at Zyntari: treat AI-generated code like code from a fast, talented junior developer who has never been on call during a breach. A great starting point, never the finished product. Review the auth, review the queries, review the secrets. Then ship.