DEV Community: Nexius Labs

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.