AI agents in operations: automating the boring middle

By Marco Lopes · January 16, 2024 · AI & Machine Learning

Most operational work does not begin or end with a difficult decision. It gets stuck in between: reading requests, finding context, checking fields, chasing missing information, copying updates, and making sure the right person sees the right thing.

We call this the boring middle. It connects the systems we already have, but it often depends on someone remembering the next step.

At Kordspace, we work remotely across software, AI, Web3, hardware, and design. That makes us interested in AI agents less as digital personalities and more as practical coordination tools. Where can they remove repetitive work? Where should they stop? How do we make their actions inspectable?

Our answer is to start with bounded workflows, not an autonomous replacement for the operations team.

What we mean by an operational agent

For our purposes, an AI agent is a system that uses a model to interpret a goal or input, select from available tools, and move a task toward completion. Those tools might search documentation, retrieve a ticket, draft a response, or propose an update to another system.

The important distinction is not whether the interface looks like chat. It is whether model output influences what happens next.

As of January 2024, language models are useful at extracting information, summarising messy material, and proposing next steps. They remain capable of misunderstanding instructions, inventing details, and choosing inappropriate actions. We therefore treat an agent as an unreliable reasoning component inside a reliable software boundary.

The model can suggest. Application code must decide what is permitted, validate the inputs, and control execution.

Choose the boring middle, not the critical endpoint

We look for work that is frequent, text-heavy, and easy to verify. Good starting points include support triage, internal request routing, document collection, project handovers, and preparation of status updates.

Consider an incoming supplier request. Someone reads the email, checks whether required information is present, finds the relevant internal policy, and prepares a record for review. An agent could assist with most of that preparation without approving the supplier or authorising payment.

That separation matters. Reading a document and drafting a checklist have different consequences from changing bank details.

We ask three questions before choosing a workflow:

• Can we describe a successful outcome without saying “use good judgement”?
• Can we verify the result against an authoritative source?
• Can we reverse or safely discard an incorrect result?

If those answers are unclear, we narrow the task before adding autonomy.

Map the workflow before selecting a model

A surprising amount of agent design is ordinary process design. We first write down the trigger, required inputs, source systems, decision points, owner, and completion condition.

We also map the exceptions. What happens when a customer identifier is missing? What if two records disagree? Who handles a request that does not fit an existing category?

Without those answers, an agent tends to reproduce an ambiguous process faster rather than improve it.

Our workflow specification separates three kinds of work:

• Deterministic: checking required fields, comparing dates, enforcing permissions.
• Model-assisted: interpreting free text, summarising evidence, suggesting a category.
• Human-owned: approving consequential changes, resolving ambiguity, granting exceptions.

We keep deterministic work in code. There is little value in asking a language model whether a required field is empty. We use the model where language and context genuinely make the task difficult.

Start with a narrow assistant and explicit states

For a first implementation, we prefer a controlled sequence over a free-running loop. A request might move through received, context_loaded, draft_ready, awaiting_review, and completed.

Each transition has a condition. The model cannot declare the request complete merely because its response sounds confident.

In our supplier-request example, the system could:

1. Extract the requested service and supplied identifiers.
2. Retrieve the applicable onboarding requirements.
3. Compare the submitted material with those requirements.
4. Produce a draft checklist with links to supporting evidence.
5. Queue the draft for an authorised reviewer.

Missing or contradictory evidence sends the request to an exception state, not another round of guessing.

We also set limits on tool calls, elapsed time, and retries. An agent that keeps searching indefinitely is not being diligent; it is consuming resources without a clear completion path.

Build on familiar cloud components

Google Cloud is our preferred starting point, but we do not need a special platform for every part of an agent.

A practical architecture could use Cloud Run for the application and tool endpoints, Pub/Sub for incoming events, Cloud Tasks for controlled background execution, and Firestore or Cloud SQL for workflow state. We can use Vertex AI for model access, Secret Manager for credentials, and Cloud Logging and Cloud Monitoring for operational visibility.

Cloud Workflows can coordinate predefined steps when an explicit orchestrator is useful. We choose components according to the workflow, rather than adding every service by default.

For organisations already committed to AWS or Azure, the same boundaries apply using their managed equivalents. We prioritise identity, networking, data location, and maintainability over a cloud migration just to run an agent.

The architecture should remain understandable when the model is temporarily unavailable. Requests should wait, retry safely, or move to a human queue.

Give the agent tools, not unrestricted access

Tool design is where a promising demo becomes a controlled application.

We expose specific operations such as get_request, search_policy, and create_draft. We avoid broad capabilities such as arbitrary SQL execution, unrestricted shell access, or a generic HTTP tool that can reach anything.

Each tool needs a schema, permission checks, clear error responses, and a defined effect. Read operations and write operations should be distinguishable. The server must validate model-generated arguments rather than assume that structured output is correct.

We carry the initiating user’s authorisation context through the workflow. A shared service account must not become a way to retrieve records that the requester could not access directly.

For consequential actions, approval must happen outside the model’s discretion. We bind approval to the exact proposed change and recheck relevant conditions before execution. A vague “approved” message should not unlock unrelated actions.

Treat retrieved content as evidence, not instructions

Operational agents often read emails, uploaded documents, support messages, and knowledge-base pages. Those sources can contain malicious instructions as easily as useful information.

A document might tell the agent to ignore its rules, reveal private data, or call an unrelated tool. We treat that as untrusted content, not a new instruction from the system owner.

Prompt wording helps establish the distinction, but it is not a security boundary. We also restrict tool permissions, validate destinations, limit outbound access, and minimise what sensitive information reaches the model.

Retrieval must respect document-level access controls. We preserve source references so reviewers can inspect the evidence behind a proposed action.

We also decide explicitly which inputs, prompts, and outputs are retained. Operational observability should not quietly create a second, less-controlled store of customer or employee information.

Make side effects safe to retry

Distributed systems retry. Messages may arrive more than once, services may time out, and a tool can succeed even when its response never reaches the caller.

An agent does not remove these problems. It can make them harder to notice because a conversational response may hide an uncertain execution state.

We use stable workflow identifiers and idempotency keys for supported write operations. We record execution attempts and receipts, and use transactional state changes where the underlying system allows them.

If a third-party API lacks idempotency support, we add duplicate detection or reconcile the remote state before retrying. We do not blindly repeat an action just because the model asks again.

A useful rule is that the agent may explain an action, but only a verified tool result can confirm it happened. “We updated the record” must follow an actual successful update.

Design the review screen as carefully as the prompt

Human approval is not meaningful if the reviewer sees only a polished paragraph and an approve button.

We show the original request, relevant evidence, proposed field changes, unresolved questions, and the consequences of accepting the draft. Reviewers should be able to edit, reject, or route the task elsewhere without fighting the interface.

We avoid presenting model confidence as proof of correctness. A fluent answer is not necessarily a well-supported one. Missing evidence deserves a visible warning, even when the wording sounds certain.

For a remote team, ownership also needs to be explicit. Every exception should have an assigned queue or person, a visible status, and a route back into the workflow.

Otherwise, automation simply moves the boring middle into a new dashboard that nobody remembers to check.

Evaluate the workflow, not just the response

Before enabling writes, we assemble a representative evaluation set from permitted historical material or clearly labelled synthetic examples. It should include incomplete requests, conflicting records, unusual formatting, tool failures, and attempts to manipulate the agent through retrieved content.

We measure whether the workflow reaches the correct state, extracts the right fields, cites relevant evidence, and escalates when it should. We also track unauthorised-action attempts, duplicate effects, review effort, latency, and cost per completed task.

We compare the assisted process with the existing process. Generating a draft quickly is not an improvement if someone spends longer correcting it than preparing it manually.

Model versions, prompts, retrieval settings, and tool schemas belong under change control. We rerun evaluations when any of them changes.

Our rollout begins in shadow mode, progresses to draft-only assistance, and adds narrowly scoped actions only when the evidence supports doing so.

A short checklist before launch

Before we put an operational agent in front of a team, we check that:

• The task has a named owner and a clear completion condition.
• Model-assisted decisions are separated from deterministic checks.
• Tools enforce least privilege and validate every argument.
• Retrieved content cannot grant permissions or bypass approvals.
• Consequential changes require review of the exact proposed action.
• Retries cannot silently create duplicate side effects.
• Logs support investigation without unnecessary sensitive data.
• Evaluation includes ambiguity, malicious input, and service failures.
• A pause switch, manual fallback, and rollback procedure exist.

We keep the first release deliberately small. One dependable workflow teaches us more than a broad agent that requires constant supervision.

Automate coordination without hiding accountability

The opportunity is not to make operations disappear. It is to reduce the attention spent moving information between people and systems while preserving the judgement that keeps the organisation working.

We see the strongest starting point in agents that gather context, prepare evidence-backed drafts, and carry out limited, authorised actions. They should make uncertainty visible and hand control back gracefully. That is less theatrical than an autonomous digital employee, but much more useful.

If we can help identify and automate the boring middle in your operations, start a project with Kordspace. To explore how we bring software, AI, cloud infrastructure, and design together, read our related services pages.