DEV Community: Nexius Labs

Your AI Agent Has the Permissions of an Insider

Nexius Labs — Thu, 13 Aug 2026 12:26:57 +0000

An AI agent with tools behaves less like a chatbot and more like an insider account. It can read, decide and act across systems at machine speed. The security design must therefore start with authority: what the agent can reach, what it can change and how quickly the team can stop it.

Reading a document is an action. So is running a command, installing a package, querying a customer database, sending an email or calling an API. Each tool turns a model response into a change in the world. The useful question is therefore not whether the model is intelligent enough to use a tool. It is whether the system has limited what that tool can do when the model is wrong, manipulated or operating on compromised inputs.

That distinction now matters in production.

Anthropic's analysis of the GTG-1002 cyber-espionage campaign describes an operator using an AI agent to chain reconnaissance, exploitation, lateral movement and data collection. The model was dangerous because the surrounding software gave it tools, continuity and room to act across several stages of an intrusion.

Software supply chains show the same pattern from another direction. GitHub reported a sustained wave of attacks against package repositories and CI/CD systems. Its 2026 response included safer workflow defaults, staged npm publishing, tighter trigger controls, restrictions on install scripts and faster credential revocation. Those controls do not depend on every developer or automated process making a perfect decision. They limit what one compromised account, package or workflow can do next.

Agents need the same treatment.

The model is one part of the attack surface

Teams often review the model, prompt and output while paying less attention to the execution environment around them. The larger risk sits in the combination:

The files and records the agent can read
The commands and tools it can invoke
The credentials available during a run
The packages and external services it can introduce
The actions it can complete without approval
The memory it can carry into later sessions

A prompt injection hidden in a web page or document may look like data to a human and like an instruction to an agent. NIST describes this as agent hijacking: untrusted content enters the same context as trusted instructions and redirects the agent toward an unwanted action.

The model may also make an ordinary mistake. It can target the wrong environment, misunderstand the requested scope or select a package with a deceptive name. Security cannot rely on the agent recognizing every trap. The surrounding system must make a bad decision cheap to stop and small enough to recover from.

Start with an authority map

Before deployment, write down the agent's authority in operational terms.

For every tool, specify what the agent may read, propose, change and release. Name the conditions that require a person. Name the person who owns the exception. Decide how the action will be reversed.

“Access to GitHub” is too broad. A useful authority definition might allow an agent to read two repositories, create a branch and open a draft pull request. It would deny changes to branch protection, repository secrets, billing, membership and production releases.

“Access to finance” is equally vague. An accounts-receivable agent may read approved invoice records and prepare follow-up drafts. It should not change bank details, issue refunds or release payments with the same identity.

This map exposes dangerous combinations. An agent that can read untrusted content, retrieve production credentials and execute arbitrary commands has several stages of an attack chain in one session. Separate those powers before refining the prompt.

Give each run the smallest useful identity

Agents should not borrow a founder's or administrator's standing access. Give the agent its own identity, then bind credentials to the task, resource and time window.

A research run may receive read-only access to a defined folder for 30 minutes. A deployment run may write to a staging environment but require a separate approval for production. A support agent may retrieve one customer's records after the ticket system provides a verified customer identifier.

Short-lived, workflow-bound credentials reduce the value of anything an attacker extracts. They also produce cleaner logs because actions belong to a named agent and run instead of disappearing under a shared human account.

Least privilege is not a one-time configuration. Tools, integrations and job scope change. Recheck permissions whenever an agent gains a new data source, model, package manager, memory store or execution tool.

Separate preparation from release

Most useful agent work has a reversible preparation stage and a consequential release stage.

Let the agent prepare the email, payment batch, database migration, infrastructure plan or package update. Run checks on the prepared result. Require a policy check or human approval before the system sends, pays, migrates, deploys or publishes.

The approval should show the actual proposed action, affected resources, evidence used and expected impact. A button labelled “Approve” beside a vague summary creates ceremony, not control.

Approval gates also need thresholds. A support agent might send an approved template automatically but escalate any message containing a refund, legal claim or account closure. A coding agent might merge a documentation fix after tests pass but stop when a change touches authentication, dependencies, secrets or infrastructure.

The point is to reserve attention for consequences, not to place a person in every loop.

Treat packages and tools as executable authority

Package installation is remote code intake. An agent with permission to select and install dependencies can import someone else's software into the environment, often with scripts that execute during installation.

Pin versions. Use lockfiles and allowlists. Verify package provenance. Disable install-time scripts by default where the ecosystem permits it. Scan the dependency and run it in an isolated environment before it reaches sensitive credentials or production data.

Apply the same discipline to agent tools and MCP servers. A tool description is not a security boundary. Verify where the tool came from, what code runs, which network destinations it can reach and which credentials it receives.

Supply-chain safety improves when trust takes time. GitHub's package cooldowns and staged npm publishing create a gap between a new release and broad execution. Agent workflows can adopt the same idea: quarantine new tools and dependency versions until checks and observation establish a reason to trust them.

Log decisions, tool calls and effects

Chat transcripts are not sufficient audit logs.

Record the agent identity, run ID, initiating user, model and tool versions, data sources, requested action, parameters, approval decision, resulting system change and error state. Protect the logs from the same agent being monitored.

Good logs answer practical questions during an incident:

Which files did the agent read?
Which commands ran and with what arguments?
Which credentials or roles were active?
What left the network, and where did it go?
Who approved the consequential action?
Which later runs reused the affected output or memory?

NIST's current work on agent systems places strong emphasis on constrained access, monitoring and machine-readable audit trails. That evidence supports both accountability and faster recovery.

Design rollback before autonomy

Every production agent needs a stop path and a recovery path.

You should be able to revoke its credentials, end active sessions, block network access, isolate generated artifacts and identify every system it changed. Mutable actions need backups, version history, transaction boundaries or compensating actions.

Test the rollback. A written procedure that depends on the same compromised credentials, unavailable administrator or damaged logs will fail when needed.

A simple pre-deployment exercise is useful: assume the agent follows a malicious instruction in the next document it reads. Ask what it could access, what it could change, how far the change could propagate and how long the team would need to detect and reverse it. The answers reveal the real blast radius.

Governability is a deployment capability

Agent security does not require removing useful tools. It requires making authority explicit.

The strongest production pattern is controlled execution: narrow identities, isolated environments, trusted inputs, staged actions, meaningful approvals, protected evidence and rehearsed rollback. Nexius Labs describes the wider operating discipline as Human Control and Mission Control, where agent work has named ownership, bounded authority and visible escalation.

Start with one workflow. List every tool and permission. Remove standing credentials. Separate preparation from release. Add logs that capture effects, then run a rollback drill before increasing autonomy.

An agent can move quickly without holding the keys to everything.

Sources

Originally published by Nexius Labs on Medium: Agent Security Is an Authority Problem.

A Five-Loop Operating Model for a One-Person AI Company

Nexius Labs — Mon, 10 Aug 2026 23:34:49 +0000

AI lets a founder test and operate a business with far less headcount than a traditional company. It does not remove the need for sales, delivery, support, finance, or control.

The practical design question is how to divide those functions into jobs that agents can execute without giving one model vague authority over the company.

A useful one-person AI company has one accountable founder and five operating loops. Each loop has defined inputs, permitted actions, acceptance tests, and an exception route.

1. Demand and revenue

This loop identifies suitable prospects and moves good opportunities toward a sale.

Agents can monitor a defined market, enrich lead records, prepare account briefs, repurpose approved content, and draft personalised outreach. The founder owns positioning, qualification rules, important sales conversations, pricing, and the final customer commitment.

Measure qualified conversations and accepted proposals. Message volume is not a business result.

2. Delivery

This loop converts a customer promise into an accepted outcome.

For a product business, agents can triage feedback, prepare implementation plans, write test cases, and draft release notes. For a service business, they can assemble research, prepare analysis, build workshop material, or check deliverables against a rubric.

The founder owns the delivery standard and any judgement that changes scope, risk, or customer expectations.

3. Customer operations

This loop receives questions, resolves routine issues, and catches signs of dissatisfaction.

Agents can classify requests, retrieve approved answers, draft replies, update records, and escalate cases outside policy. Refunds, contract exceptions, sensitive complaints, and uncertain answers should reach the founder or an authorised specialist.

Optimise for dependable resolution, not the shortest response time.

4. Finance and administration

This loop keeps the company solvent and compliant.

Agents can match invoices to records, prepare receivables follow-ups, categorise expenses, assemble monthly reporting packs, and flag missing documents. They should not silently approve payments, change bank details, submit regulated filings, or invent an accounting treatment.

A solo founder may still need an accountant, lawyer, or company secretary. AI can reduce the cost of preparing clean information for those experts. It does not replace their accountability or domain judgement.

5. Control and improvement

This loop watches the other four.

It records what agents did, which sources they used, how much each run cost, where humans intervened, and whether the output was accepted. It also tracks failures and changes the instructions, tools, or routing rules that caused them.

Without this loop, automation creates invisible operational debt. The founder saves ten minutes producing a draft and loses an hour repairing a bad action downstream.

Nexius Labs describes the required operating discipline as Human Control and Mission Control: named ownership, bounded permissions, approval points, evidence, escalation, and accountability around agent work.

Specify agent jobs as contracts

“Grow the company” is an ambition. “Prepare a weekly list of ten accounts that match these criteria, with a source for every claim” is a job.

Every agent job needs:

A trigger that starts the work
A defined set of information the agent may use
A bounded action or output
A test that determines whether the result is acceptable
An exception route for uncertainty or failure
A named human who remains responsible

Authority needs the same precision. An agent may draft an email without permission to send it. It may prepare a payment batch without permission to release funds. It may suggest a contract change without permission to bind the company.

These boundaries let the founder review consequential decisions instead of rereading every low-risk task.

Track the cost of accepted work

Subscription prices do not reveal the economics of an agent-run company. Use this calculation instead:

AI and tool cost + founder review time + retries + correction work + external expert cost

Divide that total by the number of outputs customers or internal users accepted.

A cheap model can become expensive after review. A premium model is wasteful when a deterministic rule or smaller model could complete the job. The right choice depends on task difficulty, the consequence of failure, and the cost of verification.

Start with one sellable loop

Start with one product or service, one customer segment, and one repeated delivery loop. Write the promise in plain language. Map the steps from request to accepted outcome. Mark the decisions that need human judgement, then automate the stable work around them.

For the first 30 days, record:

Time from request to delivery
Percentage of outputs accepted without rework
Founder review minutes per output
Total operating cost per accepted outcome

Add another agent only when a repeated bottleneck is visible. Add a human specialist when the work requires trust, accountability, deep domain judgement, or a relationship that customers value.

One owner, a narrow promise, five visible loops, controlled agents, and outside expertise where the stakes require it are enough to build a real company before building a large team.

Originally published by Nexius Labs on Medium.

Agent-Ready Work Is the Bottleneck Nobody Sees

Nexius Labs — Sun, 09 Aug 2026 07:32:27 +0000

Companies are adding AI agents faster than they are redesigning work for them.

Giving an agent access to email, documents, a CRM, and a task manager may create the appearance of capability. It does not give the agent a well-defined job.

Consider an instruction such as “support the sales team.”

What should the agent do first? Which accounts should it examine? May it change CRM records? Can it contact a prospect? Which claims may it make? When should it ask for approval? How will the sales manager know that the work is complete?

A human employee can often resolve these gaps through experience, observation, and conversations with colleagues. A digital coworker needs the operating rules to be made explicit.

This is the next AI bottleneck: agent-ready work.

Most work was designed for human interpretation

Business processes contain more unwritten judgment than their standard operating procedures suggest.

A customer-service representative knows when an angry message requires immediate escalation. A finance officer recognises an unusual invoice even when every required field is present. An account manager can tell when a technically accurate response would damage a client relationship.

People learn these rules through context and repetition. They ask questions, observe how managers handle exceptions, and build judgment over time.

Agents do not inherit that organisational context when they receive system access.

An agent may have enough technical capability to read a customer record, draft an email, and update a ticket. It still needs to know which information is authoritative, which actions are permitted, and which situations require human judgment.

The organisation must package that knowledge into the work.

Agent-ready work has seven parts

1. What is the objective?

“Review customer accounts” is an activity. “Identify customers whose contracts expire within 90 days and prepare a renewal brief for the account owner” is an objective.

The second version gives the agent a defined result and an identifiable recipient.

2. What triggers the work?

The agent needs a reliable starting event.

That event could be a new invoice, an unanswered support ticket, a contract reaching a specified date, or a record entering a particular CRM stage. A clear trigger prevents duplicate work and arbitrary execution.

3. Which inputs are approved?

The agent should know which sources it may trust.

For a renewal brief, approved inputs might include the signed contract, CRM activity, support history, payment status, and product-usage records. An old sales presentation or an unverified web result may provide misleading context.

Data readiness becomes an operating requirement when agents participate in workflows.

4. What are the authority boundaries?

The organisation must specify what the agent can read, suggest, write, approve, expose, and reverse.

A renewal agent may prepare a brief and create a CRM task. It may need approval before changing the opportunity value or sending a message to the customer. It should never invent a discount or contractual commitment.

Permissions should reflect the job rather than the maximum capability of the connected tools.

5. What evidence must the agent provide?

A useful output needs supporting evidence.

The renewal brief should identify the contract date, current commercial terms, open support issues, recent account activity, and source records used. The account manager can then review the recommendation without repeating the entire investigation.

Evidence also creates an audit trail when a decision is questioned later.

6. When must the agent escalate?

Exceptions are part of the workflow.

The agent should escalate when source records conflict, required information is missing, the proposed action exceeds its authority, or the situation requires commercial judgment.

Every escalation needs an owner. Sending an exception into a general queue without an accountable recipient merely relocates the problem.

7. What counts as done?

Completion must be observable.

For the renewal example, “done” might mean that the brief has been saved, its evidence has been attached, a task has been assigned to the account owner, and the workflow status has been updated.

Producing a plausible paragraph does not complete an operational process.

Permission maps create practical trust

Trust in an agent should come from visible controls.

A permission map defines which actions the agent can take at each level of risk. For example:

Read an approved customer record automatically
Suggest a CRM correction with supporting evidence
Create an internal follow-up task
Request approval before contacting a customer
Block changes to prices, contracts, and payment terms
Record who approved each consequential action
Provide a recovery path for incorrect updates

These permissions can expand as the workflow demonstrates predictable behaviour. The first production version should usually handle narrow, reversible actions while humans retain control over sensitive decisions.

This approach gives operators a practical basis for trust. They can see what the agent is allowed to do, inspect what it did, and intervene when required.

Domain experts must architect the work

The hardest part of preparing work for an agent is rarely writing the prompt.

The real work is identifying the rules, evidence, exceptions, and judgment points that experienced employees apply every day.

That makes domain experts central to agent design.

A finance officer can explain which invoice mismatches are routine and which indicate risk. A customer-service leader can define when a complaint requires management attention. A procurement manager can identify which supplier changes demand additional checks.

Their knowledge must be converted into workflow rules, decision tables, examples, permission boundaries, and escalation paths.

The technical team connects models and systems. The domain expert defines what responsible execution means.

This is how domain experts become AI architects.

The Agent Boss packages and reviews work

Managers of digital coworkers need a different delegation discipline.

They must define expected outcomes, establish authority, inspect evidence, manage exceptions, and decide when an agent has earned additional responsibility.

That is the role of the Agent Boss.

An Agent Boss should be able to answer:

Which workflows are delegated?
Who owns each workflow?
What may each agent change?
Where is human approval required?
How are failed actions recovered?
Which evidence is retained?
How is performance measured?

Without these answers, adding agents increases operational ambiguity. With them, digital coworkers can become accountable participants in the business.

Start with one work packet

Choose one recurring workflow with clear boundaries and a named owner.

Observe how employees currently perform it. Record the information they use, the decisions they make, the exceptions they encounter, and the evidence they need.

Turn that knowledge into a work packet containing:

Objective
Trigger
Approved inputs
Permission boundaries
Required evidence
Escalation conditions
Done state

Run the agent in shadow mode first. Let it prepare recommendations without executing consequential actions. Compare its work with the operator’s decisions and identify missing rules.

Allow limited execution once the team can inspect every case and recover safely from failures. Expand the scope only when the operating evidence supports it.

The number of agents is a poor measure of progress. Measure completed work, exception rates, human interventions, recovery time, evidence quality, and business outcomes.

AI becomes part of the operating system when work can be delegated with clear authority and accountability.

If your team is moving from AI experiments to AI execution, Nexius Labs helps businesses design governed AI workflows, digital coworkers, and agentic operating systems.

Nexius Labs describes the controlled environment around a reliable agent as Harness Engineering: context, tools, permissions, tests, observability and recovery.

Can Your Application Be Operated Safely by AI Agents?

Nexius Labs — Sun, 09 Aug 2026 07:28:59 +0000

If your software cannot be used by your agents, it is not ready for the next operating model.

Most companies still build software for one user: a human sitting in front of a screen.

That made sense for the last era of work. People logged in, clicked through menus, copied data between systems, chased approvals, checked dashboards, and updated records manually.

That is not where work is going.

If we are serious about digital coworkers, agentic workflows, and AI moving from chat to execution, we need to change how we design applications. Every application should answer a more demanding question than “Can a person use this?”

Can an agent operate it safely?

That is the standard we are applying internally now. We no longer think of applications as tools that only humans touch. Everything we build needs to be usable by the agents that support our work.

I put a simple readiness checklist in the gist Can This App Be Agentified?. It helps us decide whether an application can be operated by agents or needs remediation first.

A polished UI is not enough

A lot of teams confuse usability with operability.

A clean interface helps humans. It does not automatically help agents. An agent needs a reliable way to understand the system, take action, verify the result, and escalate when risk crosses a threshold.

Every app therefore needs more than screens. It needs a control surface: an API, service layer, workflow endpoint, structured database interface, event queue, or set of safe actions exposed to agents.

Without one, the agent becomes a fragile screen-clicking assistant. It has to guess where buttons are, read changing layouts, and rely on UI state instead of system state. It breaks when someone changes a label or moves a modal.

That is automating around bad architecture.

The six checks we use

The checklist breaks agent readiness into six signals.

1. Resource model

Can the app clearly describe the things it manages?

Those things might be a customer, invoice, ticket, booking, task, lead, approval request, or training enrolment.

If the app has no clean resource model, the agent has no stable object to work with. It may see text on a page, but it does not know what the object is, what state it is in, or which actions are valid.

Humans can infer messy context. Agents need structure.

2. API or control surface

Can the agent take action without relying only on the UI?

Many applications fail here. They have a decent interface for people but no practical way for an agent to create, update, retrieve, or trigger anything safely.

If every workflow depends on clicking through screens, the app is not agent-ready yet. It may still be useful, but it needs remediation before agents should operate it at scale.

3. Permissions

Can we define exactly what the agent is allowed to do?

Agents should not operate with vague access. A sales agent may update CRM notes but should not change contract terms. A finance agent may prepare an invoice but should not approve payment. A training operations agent may check enrolment status but should not override eligibility rules.

Agent-ready applications need permission boundaries that match real business authority. Not every action should be available to every agent.

4. UI blockers

Are there steps that still require a human to stare at a screen?

Some blockers are obvious:

captchas
hidden modals
drag-and-drop-only actions
unstructured forms
unpredictable popups
workflows with no system readback

Others are more subtle. An app may require users to visually compare two records before confirming a change. That can work for a human operator, but it is poor for an agent unless the comparison data is exposed clearly.

The UI does not always need to disappear. The underlying workflow needs to be exposed in a form an agent can use safely.

5. Trust gate

What happens when the action is risky?

Agent-ready does not mean fully autonomous for everything. Some actions should still require approval. Approval should be designed into the workflow instead of handled through random Slack messages and manual screenshots.

A good trust gate tells the agent when to proceed, when to ask, who can approve, what evidence to show, and what to log after the decision.

That is how you keep humans in the loop without keeping humans in every loop.

6. Audit and readback

Can the agent verify what happened after it acts?

This is non-negotiable. If an agent updates a customer record, it needs to read back the record and confirm the change. If it triggers a workflow, it needs to know whether the workflow started, failed, or completed. If it escalates for approval, it needs to know who approved, when they approved, and what was approved.

Without readback, you do not have reliable execution. You have a request sent into the dark.

Design operating surfaces, not just features

Most software teams still think in terms of features: what can the user do?

Agentic companies need to design operating surfaces: what can a human, agent, or workflow safely coordinate through this system?

That shift changes product design. Schemas, permissions, logs, event states, rollback paths, and exception queues become first-class concerns. Screens that look complete but still require a person to copy, paste, chase, check, and update are no longer enough.

That is the work we want to remove, not because humans do not matter, but because humans should not be trapped operating software that should be operating with them.

Build for digital coworkers from day one

The next generation of applications will be judged by how well they can be orchestrated.

Can agents understand the system? Can they act through safe interfaces? Can they escalate risky decisions? Can they prove what happened? Can they work alongside humans without turning every workflow into another manual checkpoint?

If an app cannot be used by your agents, it is not ready for the next operating model.

Use the agent-readiness checklist on one application this week. If it fails one of the six checks, you have found the next remediation task.

The Nexius guide to connected AI applications and systems shows how agents can work with ERP, CRM and operational systems without weakening the authoritative system of record.

Your AI Agent Costs Too Much Because Its Job Is Undefined

Nexius Labs — Sun, 09 Aug 2026 07:22:24 +0000

Model prices matter, but the largest waste often starts before the first token is billed. Undefined jobs make agents read too much, retain stale context, retry without a new strategy and call expensive models for routine work.

The useful metric is not cost per token. It is cost per accepted task.

Price the completed job, not the individual token

Token prices are useful for procurement. They are a poor measure of whether an agent is economical.

Suppose one model costs half as much per million tokens but needs three attempts to produce an acceptable result. Another model costs more per token but completes the job once, with the right evidence and format. The cheaper model may create the more expensive workflow.

The useful unit is cost per accepted task.

For each recurring agent job, track:

input tokens
cached input tokens
output and reasoning tokens
tool calls
retries
elapsed time
human review time
whether the result passed the acceptance check

OpenAI separates input, output, cached, and reasoning tokens in its usage reporting. Anthropic exposes input, output, cache-write, and cache-read usage for Claude. Those fields become meaningful when they sit beside the business outcome.

“This run used 80,000 tokens” tells you very little. “This agent resolved 42 support cases at $0.18 per accepted case, with four escalations and two reworks” gives an operator something to manage.

Give the agent a bounded job

An agent job needs six parts:

Trigger: What starts the work?
Approved inputs: Which records may it read?
Permitted actions: Which tools may it use, and with what authority?
Output: What must it produce?
Acceptance check: How will the system or reviewer decide that the work passes?
Stop and escalation rules: When must it stop, ask, or hand the work over?

Consider a weekly sales-pipeline agent.

“Analyse the CRM and tell me what matters” gives the agent an unlimited reading assignment. It may scan years of records, revisit dead opportunities, search the web for every account, and produce a long report that nobody can act on.

A bounded job looks different:

Every Friday at 4pm, review open opportunities changed in the past 14 days. Flag records with no next action, a close date in the past, or a value above $25,000 with no activity for seven days. Produce a table with the opportunity, issue, supporting CRM fields, and recommended owner action. Do not change CRM records. Escalate missing or conflicting data to the sales operations lead.

Every Friday at 4pm, review open opportunities changed in the past 14 days. Flag records with no next action, a close date in the past, or a value above $25,000 with no activity for seven days. Produce a table with the opportunity, issue, supporting CRM fields, and recommended owner action. Do not change CRM records. Escalate missing or conflicting data to the sales operations lead.

The second version defines the query window, rules, evidence, output, permissions, and escalation path. The agent has less freedom, but it has a much better chance of completing the work in one pass.

Context is an operating budget

Teams often treat a large context window as permission to keep everything.

Long-running agents accumulate conversation history, tool schemas, retrieved documents, screenshots, intermediate reasoning, failed attempts, and raw tool output. Much of that material helped at one point. It does not need to travel through every later step.

Model providers have built cost controls around this problem. Anthropic’s context-management guidance recommends compaction for long-running conversations and selective removal when finer control is required. Google Cloud’s context-caching guidance describes the cost and latency created when applications repeatedly send the same documents, instructions, or media for processing.

Use three context layers:

Stable context: policies, tool definitions, schemas, and instructions that rarely change
Task context: the records and evidence needed for the current job
Working context: temporary tool results and intermediate notes that can be discarded after the step

Stable context is a candidate for caching. Task context should be retrieved narrowly. Working context should expire.

Prompt caching can reduce the price of reused input, but it does not make irrelevant context useful. Anthropic’s prompt-caching documentation and OpenAI’s prompt-caching guidance both reward repeated, stable prompt prefixes. A prompt that changes on every run will miss the cache. A bloated prompt can still cost less when cached while remaining slow, distracting, and hard to debug.

Context policy belongs in the runtime design, alongside access control and retry policy.

Put a budget around retries and parallel work

Retries make agents look persistent. Unbounded retries make them expensive and unpredictable.

Each retry should answer a specific failure:

Was a tool temporarily unavailable?
Did the output fail a schema check?
Was required evidence missing?
Did the model misunderstand the task?
Has anything changed that makes another attempt likely to succeed?

If the answer is unclear, another identical attempt is gambling with tokens.

Set a maximum attempt count for each step. Change the strategy before retrying. Use a cheaper model for extraction or classification, then route ambiguous cases to a stronger model. Stop and escalate when the same error repeats.

Apply the same discipline to parallel agents. Five agents researching the same question can provide breadth, or they can produce five overlapping summaries that a sixth agent must reconcile. Parallel work earns its cost when the tasks are independent, the expected outputs differ, and the coordinator knows how to combine them.

Give every branch a purpose, a token or time ceiling, and a return format.

Acceptance criteria reduce rework

An agent can complete every technical step and still fail the job.

A content agent may publish a grammatically clean article that sounds generic. A support agent may draft a polite answer without resolving the customer’s issue. A research agent may collect twenty sources without identifying which claim each source supports.

Acceptance criteria should be testable before the agent starts.

For a research brief, that might mean:

every factual claim has a primary source
sources fall within the specified date range
conflicting evidence is identified
the final brief stays under 800 words
the recommendation names an owner and next action

The agent can check most of those conditions before handing the work to a person. Early checks are cheaper than full reruns.

Human review also needs a defined decision. Ask the reviewer to approve, reject with a reason code, or escalate. Free-form feedback such as “make it better” sends the agent back into another undefined job.

Run a 30-minute cost review

Choose one agent workflow that runs often enough to matter. Pull ten recent executions and record the total tokens, tool calls, retries, duration, review time, and pass rate.

Then inspect the expensive runs:

Which context was repeatedly sent but rarely used?
Which step used a stronger model than the decision required?
Which retries repeated the same strategy?
Which tool results remained in context after their useful step?
Which missing acceptance rule caused rework?

Change one boundary at a time and measure the next ten runs. Shorten the retrieval window. Cache the stable prefix. Cap retries. Route routine steps to a smaller model. Add a schema check before human review.

Do not optimise for the lowest token count. Optimise for the lowest cost that still produces an accepted result at the required speed and risk level.

Before buying another subscription or moving the whole workflow to a cheaper model, write the agent’s job in six lines: trigger, inputs, actions, output, acceptance check, and stop rule. If those lines remain vague, the cost will remain unpredictable.

The Nexius Labs guide to Loop Engineering and token efficiency explains why AI cost should be measured per successful outcome — not merely per model call.

How to Route AI Work Across Open and Frontier Models

Nexius Labs — Sun, 09 Aug 2026 07:13:30 +0000

A business does not have one AI job. It has many small decisions with different privacy, latency, cost, quality and risk requirements.

That makes model selection a routing problem, not a brand contest. Open-weight models give teams control over execution and adaptation. Managed frontier APIs provide advanced reasoning and tooling without the infrastructure burden.

The practical stack uses both.

Open-weight and closed describe delivery models

Open-weight models make trained parameters available for download under a stated licence. Teams can run them on a workstation, private server, cloud account or specialist hosting platform, depending on model size and hardware.

The available ecosystem is already broad. The official Qwen3 repository documents local execution through tools such as llama.cpp, Ollama and LM Studio, alongside larger deployments using vLLM and SGLang. DeepSeek-V3 publishes model weights, local deployment guidance and a licence that supports commercial use. OpenAI’s gpt-oss documentation describes models designed to run on infrastructure controlled by the user.

That control creates options. It also creates work. Someone must choose the runtime, provision compute, patch dependencies, secure access, monitor performance, manage upgrades and decide which model build is approved for production.

Closed models are accessed through a provider’s product or API. The provider operates the model infrastructure and usually supplies managed scaling, model updates, safety controls and developer tooling. The customer pays for usage and works within the provider’s service boundaries.

Current API documentation shows why these models remain useful for difficult tasks. Anthropic’s thinking guidance describes reasoning across complex problems and tool results. OpenAI’s model guidance separates models and reasoning settings by capability, cost and workload.

The workflow determines where each delivery model fits.

Route the work with five questions

Before choosing a model, break the workflow into steps. Ask five questions about each step.

1. What data may the step see?

Start with the data classification.

A step that handles raw employee records, private source code, customer identifiers or unreleased financial data may need to run inside infrastructure the organisation controls. Local execution can keep that material within a defined environment when the model, runtime and surrounding tools are configured correctly.

Privacy still depends on the surrounding system. Logs, vector databases, temporary files, model servers and monitoring tools can expose data. Local execution gives the team control over that boundary and responsibility for enforcing it.

For data allowed to leave the environment, a managed API may be suitable. Review the provider’s retention, residency, training-use and contractual terms for the exact service tier. “Closed model” is too broad to serve as a data policy.

2. How repeatable is the decision?

Open-weight models fit repeatable work with stable inputs and testable outputs.

Examples include:

classifying support tickets into an approved taxonomy
extracting named fields from a known document type
removing or masking personal identifiers
rewriting content into a fixed internal format
ranking retrieved passages before another model reads them
checking whether an output matches a schema

These jobs can be evaluated with a representative test set. When a smaller self-hosted model reaches the required accuracy, sending every item to the most capable external model adds cost without improving the business result.

3. What latency and volume does the step require?

A local model can respond quickly when it is already loaded and close to the application. It can also sit idle on expensive hardware or slow down when traffic exceeds available capacity.

An API can absorb uneven demand without the customer maintaining spare compute. Network latency, rate limits and provider availability become part of the design.

Calculate the full operating cost. For open weights, include hardware, hosting, storage, engineering time, monitoring and idle capacity. For APIs, include input, output, caching, tool calls and retry costs. Compare cost per accepted task at the expected volume.

OpenAI’s gpt-oss guidance makes this trade-off explicit: model weights can be downloaded without API charges, while the user remains responsible for compute, storage and hosting costs.

4. How much control does the step need?

Open weights allow deeper adaptation. Teams can select quantisation, tune the model, constrain the serving environment, inspect the surrounding code and hold a tested version stable.

That can matter in manufacturing, regulated operations, disconnected environments and products that require predictable behaviour over a long release cycle.

Managed APIs reduce the operating burden. They can provide mature tool calling, multimodal input, structured outputs and stronger general reasoning through one interface. Version pinning and regression tests still matter because provider models and platform features evolve.

5. What happens when the model is wrong?

Error cost should decide the final route.

A weak classification can be retried or sent to a queue. A flawed legal interpretation, credit recommendation or executive statement can cause material damage.

High-consequence steps need stronger evaluation, supporting evidence and human approval regardless of model type. Frontier reasoning can improve the quality of an ambiguous analysis. Accountability stays with the organisation.

Use the best-performing tested option for judgement-heavy steps, then keep a person responsible for the decision when the risk requires one.

A hybrid workflow in practice

Consider a company analysing thousands of customer-support conversations to decide which product problems deserve attention.

The first stage contains private customer text and a large volume of repetitive work. A local open-weight model can remove personal identifiers, detect language, classify each conversation against the product taxonomy and reject records that lack enough information.

The second stage aggregates counts, recurring phrases and representative evidence. Code can perform much of this work deterministically.

The frontier model receives a smaller, policy-approved evidence pack. Its job is to compare themes, identify conflicts, explain likely business impact and draft an executive brief. A product leader checks the evidence and decides what enters the roadmap.

This design gives each component a bounded job:

Local open-weight model: private, high-volume preparation
Deterministic code: counting, filtering and evidence assembly
Frontier API: cross-theme judgement and synthesis
Human owner: approval and prioritisation

The frontier model sees less sensitive data and fewer tokens. The local model avoids decisions beyond its tested scope. The human reviews a decision packet instead of thousands of raw conversations.

Put the routing policy in the system

A hybrid strategy needs an explicit router. Otherwise, developers will choose models case by case and the architecture will drift.

For each job type, record:

approved model or model class
permitted data classification
maximum latency and cost
required output schema
evaluation threshold
fallback model
escalation owner
conditions that require human approval

The router may be a gateway, workflow service or a small policy layer in the application. Its job is to make model selection repeatable and observable.

Log which route handled the task, the model version, token or compute usage, latency, evaluation result, retries and final disposition. Those records allow the team to replace a model without redesigning the whole workflow.

Evaluate tasks instead of defending brands

Run a model trial on work that represents production.

Choose 50 to 200 examples from one bounded task. Remove or protect sensitive data before testing external services. Define the pass criteria before running the models. Measure accuracy, evidence quality, latency, cost, failure modes and review time.

Test at least three routes:

an open-weight model inside the controlled environment
a managed frontier model through an approved API
a hybrid route where the open model prepares the work and the frontier model handles the hard cases

The result may differ by step. That is useful. A single workflow can use a small local model for 80 percent of cases, route ambiguous cases to a frontier API and send high-risk exceptions to a human.

Start with one workflow and draw its data path. Mark each step by privacy level, volume, latency, control and error cost. Assign the smallest model route that passes the acceptance test, then reserve frontier reasoning for the decisions that earn it.

At Nexius Labs, we treat this as Loop Engineering and deliberate model routing: matching each task to the model, context and acceptance threshold it actually needs.