The short answer
Opaeron's agent suite has no shared orchestration framework. Every agent is a background task with its own database table: a person starts it, it runs, it polls to completion, and the result is retrieved. The properties a framework normally supplies - durable state, human approval gates, an audit trail - came from three specific application-level patterns instead: propose-then-confirm for every write, a dedicated pgvector memory pool per context, and one non-redundant orchestrator per multi-agent workflow, written by hand rather than generated by a graph.
Why we didn't reach for a framework
Our own comparison of agentic AI frameworks lays out when LangGraph, CrewAI or the OpenAI Agents SDK earn their place: long-running workflows that need durable checkpointing, or agents that hand off to each other inside a single run. Neither describes most of what Opaeron's agents actually do.
An SEO keyword-research agent, a lead-scoring agent and a tracking-hygiene agent don't call each other mid-run. Each one is triggered once, does its own work end to end - fetch, analyse, call the model, write a result - and stops. The unit of durability we needed wasn't "resume a graph from node four," it was "a person can close the tab and check back in ten minutes." A row in a table with a status column does that. It also means every agent gets the same operational surface for free: start, list, poll, retrieve, delete, all as ordinary REST endpoints, all inspectable with the same tools you'd use on any other part of the API.
Where agents genuinely do need to compose - one workflow calling three others - we wrote that composition by hand, in Python, as application code. Not because a graph library couldn't express it, but because at three or four steps a plain function with named variables is easier to read, easier to debug and easier for the next engineer to change than a graph definition would be.
The one rule that replaces most of what a framework's safety layer would do
The rule is simple to state and easy to violate accidentally, which is why it's enforced by what code even exists to call, not by instructions to the model: no agent writes to a client account directly.
Propose, confirm, write - three separate steps, three separate authors
An agent that would change something emits a structured proposal object - never a database write. A person reviews it in the UI and confirms or edits it. A separate, non-AI code path performs the actual write and records an audit entry: who confirmed it, when, and what changed. The agent's own code has no access to the write path at all. Trust doesn't rest on the model behaving carefully that day, because the destructive capability was never on the table for it to misuse.
The audit entry isn't a courtesy log line, either - it's the actual record a person reaches for when a client asks "why did this change." Every agent run separately logs who started it, how long it ran, its outcome, and its AI cost, so a run that produced a bad recommendation and a run that produced an expensive one are both visible without adding tracing on top afterwards.
Three agents that made the architecture earn its keep
Architecture decisions sound reasonable in the abstract. These are three agents from the production suite that actually tested them.
1. A tag-hygiene agent that skips the headless browser on purpose
Checking whether a client's site has GTM, GA4, Meta Pixel, LinkedIn Insight, Hotjar, Clarity, TikTok and Google Ads installed correctly sounds like a job for Playwright: load the page, watch the network requests, see what fires. That's also the slowest and most fragile way to answer a narrower question. Most tracking tags are injected by a static script tag present in the page's raw HTML on load. Fetching that HTML and matching it against known script signatures answers "is this tag present" without a browser at all - one HTTP request instead of a browser process, no flaky waits for network idle, nothing to update when a headless Chrome version ships a breaking change. The LLM call comes after detection, to score the hygiene of what was found and recommend fixes for the account's industry. Skipping the expensive tool for the question that didn't need it was the actual optimisation, not a shortcut.
2. A lead-scoring agent with no hardcoded rules
Upload a B2B research spreadsheet - one row per account or per contact - and every row is scored end to end by the model into a Final Score out of 100 and a priority tier, with no scoring rubric written in code. The output is a copy of the original workbook with the AI's score, priority and a one-line summary added as new columns, so the person who uploaded it gets back the exact file they know, not a new format to learn. The generated file is stored inline as base64 in the database row rather than to local disk, because a containerised deployment doesn't guarantee a disk survives a restart - a small decision, but the kind that only shows up as a bug the first time a container recycles mid-review if you get it wrong upfront.
3. An orchestrator that explains what it deliberately doesn't do
The DM (digital marketing) audit agent produces a client-ready proposal by composing three separate SEO agents plus a handful of direct, synchronous health checks - uptime, SSL, domain expiry, DNS, email deliverability, DNS blacklist status. The interesting part isn't the composition, it's that the code documents which of the three agents was chosen for a reason and what it was chosen over: one bespoke site-audit path was removed in favour of reusing an existing agent confirmed to work on an arbitrary, untracked domain, and the direct health checks were added specifically because none of the three agents already covered them. Getting a multi-agent workflow right is less about the orchestration mechanics and more about knowing precisely what each piece is for, so nothing runs twice and nothing silently goes uncovered.
Memory that doesn't leak between contexts
Long-running agents need to remember what worked, and the naive version - one shared memory for everything - is actually a liability. A marketing-strategy agent's learned heuristic for one account ("target CPL is ₹500," "always compare against last year's festive season") has no business surfacing in an unrelated account's run, or in a completely different agent's context.
Opaeron's answer is a dedicated pgvector embedding pool per context rather than one global store: facts are chunked, embedded and written scoped to a config id, retrieved by similarity search at the start of a run, and carried through an outcome loop, so a heuristic that stops being true can be corrected instead of quietly repeated on every future run. The chunk/hash/embed machinery is shared code; the isolation between pools is the actual design decision, and it's enforced by which table a write lands in, not by a filter that could be forgotten in a new agent.
What we'd tell someone starting this today
- Start from the failure you're actually avoiding. "The agent might misbehave" isn't specific enough to design against. "The agent must never be able to write to a client account without a human confirming it" is a rule you can enforce in code, not just in a prompt.
- Don't reach for the expensive tool by default. A headless browser answers more questions than "is this tag present," which is exactly why it was the wrong tool for that one question.
- Compose agents in code you can read in one sitting. At three or four steps, a graph library's abstraction costs more to understand than the plain function it would replace.
- Isolate memory before you need to debug why it leaked. Deciding the scoping boundary (per account, per agent, per config) is a five-minute conversation before the first write lands, and a much longer one after.
- Log cost and outcome per run from day one. Retrofitting "why was this run expensive" onto a system that didn't plan for it means reconstructing intent from logs that weren't built for the question.
Frequently asked questions
Do you need LangGraph or CrewAI to build production AI agents?
What is a propose-then-confirm AI agent pattern?
How do you detect tracking tags without a headless browser?
How does an AI agent remember what worked across runs?
See the agents this describes
Opaeron runs twenty-plus production agents against live client data such as site crawls, search APIs and ad platforms, with every action proposed, confirmed by a person, and written to an audit log.
See the platform