AI workflows: when to use ChatGPT, builders or code

Everyone has ChatGPT or another AI assistant. Some colleagues have connected it to their files, inbox or customer database. A few have developed excellent prompts. Is that your AI strategy?

It is useful progress. But when you roll AI out across an organisation, you may notice that the best instructions belong to one person, the pilot depends on someone finding time to run it, and nobody can explain what happens when the assistant makes a mistake. Giving people a capable tool and building a dependable business process are different jobs.

I keep reaching for code when I build AI workflows because the work eventually needs a process around it. Someone must decide what the AI can read, what it can change, which rules must hold, who reviews exceptions and how the job recovers after a failure. Those decisions matter whether you use a visual builder, buy a product or commission software.

An AI workflow is a defined sequence of steps that combines model judgement with data, ordinary software and, where needed, people. Its purpose is to finish a particular job under agreed conditions. The AI might interpret an enquiry; software checks the account and applies policy; a person approves an exception.

Throughout this guide, we will follow an illustrative customer-service task. Nicola runs the team, and customers regularly ask her for a discount. The policy allows up to 10% through the normal process. Anything higher needs a manager's decision. Suppose the AI recommends 25%. Where, between that recommendation and the customer, does the system stop it?

That question gives us a useful way to compare chat, connectors, skills, workflow builders and code. It also explains why a portal, governed information and the cost of a completed job become important as AI moves into everyday work.

From individual AI use to a shared process

In Scorchsoft's Stairway to Success, we describe seven steps of AI adoption, numbered zero to six. The steps describe how AI becomes part of the business, rather than prescribing a technology for every organisation:

1. Step 0: no formal adoption. People may experiment, but the business has no agreed approach.
2. Step 1: approved access. People have suitable business accounts, guidance and tools they are allowed to use.
3. Step 2: useful individual work. Employees use AI for real tasks, learn its limits and find where it helps.
4. Step 3: shared good practice and reusable agents. Effective instructions, examples and skills become available to the team.
5. Step 4: AI configured for a specific job. A defined task gains its own process, tools, checks and owner.
6. Step 5: workflows embedded in daily work. The process runs as part of normal operations, with adoption, exceptions and value measured.
7. Step 6: AI at the heart of the business. Shared systems support several workflows and give people controlled ways to interact with them.

For Nicola, the first useful step is drafting difficult customer replies in an approved assistant. Then connectors let her look up a customer's order history before she writes. A connector links the assistant to another application; many use Model Context Protocol, or MCP, as a standard interface for tools and information.

Next, she captures her team's tone, discount policy, good examples and escalation rules in reusable instructions. A skill can package that guidance with reference material and sometimes executable helpers. Custom assistants and shared prompts can serve related purposes, although their formats and capabilities differ.

Now a new colleague can start with Nicola's experience instead of a blank chat. This is worth doing. Experimenting with skills and plugins helps you discover which evidence matters and what a useful result looks like before you commit to a larger system.

However, look at what Nicola still contributes. She chooses the right customer, spots a missing order, notices an implausible discount and decides whether to send the reply. “It works when I supervise it” is evidence that the approach has promise. The supervision is also part of the process you will need to account for.

The jump from step three to four is giving one job a defined operating process. Step five means that process has become normal work, with people using it and its results measured. Writing code alone does not achieve either step: ownership and adoption still matter.

How a skill becomes part of a workflow

You do not need to turn every line of Nicola's instructions into code. Guidance about tone may remain in the prompt. The customer identifier becomes a required field. The discount limit becomes a policy check. The instruction to ask a manager becomes an approval state that the application enforces. Good and bad example replies become evaluation cases.

Some skills remain reference material inside the production workflow; others provide reusable code or inspire its design. The useful move is deciding which instructions need stronger enforcement when the work becomes shared or unattended.

Keep improving the skill while you prototype. Record the interventions Nicola makes, because they reveal requirements that a convincing AI demonstration can hide. The skill and the operational system should improve together as you learn from real work.

When a useful prompt becomes an AI workflow

A workflow gives the task a trigger, defined stages, permitted actions and completion conditions. Nicola's discount enquiry might run like this:

1. Receive and assign: log the enquiry, identify the customer and assign an owner.
2. Gather evidence: retrieve the permitted order, contract and conversation records.
3. Draft: let the AI propose a reply, a discount and its reasons in separate fields.
4. Check: validate the proposal against policy, source records and the allowed action.
5. Review exceptions: show a manager the draft and evidence when the request needs their decision; record approval, an edit or rejection.
6. Send and record: send the authorised version through the business system, with duplicate prevention and an audit event.
7. Handle failure: route unresolved or failed jobs to a named person, preserving progress so work can resume.

The model supplies judgement at the drafting stage. Much of the work around it is ordinary software. If the customer record is missing, the process should remain incomplete and request help. A fluent reply cannot substitute for evidence that never arrived.

A good home cook and a restaurant kitchen offer a useful comparison. The cook knows how to make the meal; the kitchen has recipes, stations and a pass where someone checks the plate before it leaves. The process makes that ability usable by a team.

What is an AI agent harness?

An AI agent harness is the surrounding system that gives a model its instructions, context, tools, execution rules and operational controls. It determines how the AI receives work, makes progress, produces an output and interacts with people or other systems.

If you are ready to commission this work, our AI agent harness development service explains the scope and approach. The rest of this guide helps you decide where that level of engineering is useful.

For a simple assistant, that might involve a prompt, a small set of connectors and a person checking the answer. For a business workflow, it can include a queue of jobs, several stages, retrieval from approved sources, validation, approval screens, budgets and a record of what happened.

Think about a customer enquiry. The model might understand the message and suggest a response. The harness determines whether it can read that customer's account, whether it can view another customer's records, which facts must support its recommendation, and whether it may send the response. It also determines what happens if the customer record is unavailable.

A better model can improve the judgement inside that process. A better harness can make the whole process more effective by supplying relevant evidence, narrowing the task and preventing inappropriate actions. Both deserve attention.

The term also appears in discussions of coding agents and evaluation systems. Here, I mean the runtime and application controls for a business AI workflow. A test harness, which measures behaviour under controlled conditions, is one useful part of that wider engineering work.

ChatGPT, workflow builder, ready-made product or code?

In my Building AI Agents field guide, I describe three practical places to run AI work: personal agent environments, workflow builders and your own code. Buying a ready-made product is another route. These options offer different combinations of convenience, flexibility and ownership; their boundaries overlap as platforms gain new features.

1. A personal agent environment

You use ChatGPT, Codex or another agent environment with instructions, skills and connected tools. You remain close to the work, can redirect the agent and can inspect what it produces.

This is a good place to explore a task whose steps are still unclear. A sales manager might experiment with researching an enquiry and drafting a reply, discovering which information actually improves the response. A consultant might develop a skill for reviewing a document against a checklist.

These environments can provide permissions, approvals and other safeguards. The question is whether the available controls match your particular process. “It works when I supervise it” provides useful evidence, but leaves open what happens when another employee runs it, the inputs change or you want it to operate unattended.

Also, a personal environment is not necessarily a model running locally on your laptop. The interface, execution workspace, connectors and model inference can run in different places. Check the actual data flow before drawing privacy conclusions from the word “local”.

2. An agent or workflow builder

A visual builder lets you assemble stages, tools and branching logic with less bespoke code. Depending on the platform, it may also provide approvals, logs, structured outputs, deployment and integrations.

This is often a sensible option when the process fits the platform's features. You can make the workflow visible to the team and change it without maintaining an entire application. Some platforms support custom code too, so you can add a specialised step without rebuilding everything.

Evaluate the details that affect the outcome: permission boundaries, recovery after failure, versioning, testing, background execution and the cost of running representative jobs. A tidy canvas does not tell you whether an external action can happen twice after a retry.

3. An agent in your own code

You build the workflow inside an application, using a framework such as the OpenAI Agents SDK and your own services. You can combine model calls with ordinary functions, APIs, MCP tools, databases and user interfaces.

This gives you flexibility to implement business-specific rules and integrate with an existing product. It also gives you responsibility for deployment, security, maintenance and support. Code earns its place when those responsibilities buy control or capability that matters to the business.

4. A ready-made workflow product

Buying a product means using a process and harness someone else has built. This can be the best option when it already handles your task, permissions and exception paths well. You gain an operating foundation without owning every part of its implementation.

Ask the same practical questions you would ask of bespoke software: what can it change, what requires approval, how does it recover after failure, and can you export the records? Check integration fit, supplier support and the full running cost. A product that resembles your process in a demonstration may still need substantial configuration.

Adoption maturity and implementation choice are separate

The stairway describes how AI becomes embedded in your business. These four options describe where you implement the work. A well-run purchased workflow can be more mature than an unsupported Python script. A visual builder and a coded service can also work together.

MCP connects tools; the workflow still needs a design

Model Context Protocol, or MCP, provides a standard way for AI applications to access tools and context. It can make connecting an agent to a business system much easier. The OpenAI Agents SDK supports MCP alongside function tools, so using code does not mean abandoning connectors.

However, a connector's presence does not decide when a tool should run, which records it should expose or whether the resulting action needs approval. Those decisions depend on the host application, the MCP server, the underlying system and your workflow design.

Consider a tool that updates a CRM. A general update function may be convenient for a trusted employee. An automated workflow might need a narrower operation: attach a draft recommendation to the assigned enquiry, without changing ownership or closing the opportunity. The narrower function makes the intended action easier to validate.

MCP implementations also need appropriate authorisation and security controls. The protocol's own security guidance addresses issues such as token handling and malicious servers. A standard interface helps interoperability; you still need to decide which integrations to trust and what authority to give them.

The architectural choice is therefore not “MCP or code”. A coded harness can use MCP for useful integrations while owning the process, permissions and operational behaviour around those calls.

Where code earns its place

The reason I reach for code is that it lets me express the operating rules around AI precisely. The useful advantage comes from the checks you implement and test, rather than from the fact that the system has a codebase.

Enforce policy before a recommendation becomes an action

Back to Nicola's discount. If the 10% policy lives only in the instructions, the AI may usually follow it. The application can provide a stronger boundary: require the model to return a customer ID, discount, reasons and proposed response in separate fields, then check the discount against the authorised limit.

A 25% recommendation enters the exception queue. It cannot proceed through the normal sending path. A manager can approve an exception if they have that authority, revise it or reject it. The service applying the discount checks the permitted action again.

The message needs to match the authorised discount too. Validating a numeric field while sending free text that promises a different figure would leave a hole in the process. One approach is to assemble the offer from validated fields; another combines appropriate content checks with review. Test the whole operation.

Structured output helps software inspect a recommendation, but matching a schema does not make the facts correct. Checks against current records and a review route for ambiguity remain necessary. A second model can provide another opinion; it can also make mistakes.

“Guardrails” therefore needs a concrete meaning: identify the action you are protecting, the check that must happen before it and the system enforcing that check. A log written after sending will not un-send the email.

Put approval before the action it protects

Human review works best when the person can see the proposed action, the supporting evidence and the reason the system needs their decision. A generic “continue?” button gives them much less help.

For an outbound message, show the recipient, draft text, relevant facts and any uncertainty. For a system update, show the fields that will change. Let the reviewer approve, edit or reject, and record that decision against the work item.

The OpenAI Agents SDK documents mechanisms for pausing tool execution for approval and resuming a run afterwards. You still need to design the surrounding user experience, permissions and storage of the paused state. Approval should apply to a specific recipient, payload and record version. If those change, the system should request approval again. In Nicola's workflow, the manager approves the exact customer reply and discount they actually saw, rather than granting general authority for later changes.

Timing matters. The Python SDK's input guardrails can run in parallel with an agent, which can reduce latency but may allow tool execution before a guardrail rejects the input. Its blocking mode completes the check first. Output guardrails inspect the final output and cannot undo an earlier external action.

For that reason, place checks around the particular tool or application operation where a harmful side effect could occur. Verify the framework's current behaviour for your tool type and version, rather than assuming every guardrail covers every stage.

Approval may become lighter as evidence improves, but some actions should continue to require it. Audit records are useful after an event; they do not recover a confidential message sent to the wrong recipient. Decide the level of autonomy by the consequences of the action as well as the model's measured accuracy.

Make failure and recovery part of the design

Real workflows encounter unavailable APIs, malformed documents, timeouts and contradictory information. A production harness needs a defined response to each important failure.

Persist the work item and its progress outside the model's conversation. Record which stages completed, what remains pending and whether a person needs to intervene. A saved conversation can help resume reasoning; it is not automatically the authoritative record of a business transaction.

Retries deserve particular care. If a service creates a record and the response times out, repeating the request may create a duplicate. Use idempotency keys or another deduplication strategy where the underlying integration supports it, and reconcile uncertain outcomes before retrying consequential actions.

Separate temporary failure from insufficient evidence. An unavailable API may warrant a retry. A missing document may require a person. The AI should not invent an answer just to move the job into a completed state. Assign exceptions to a named person or queue, with a deadline where required. Give operators a way to pause new work and isolate a faulty integration, with clear behaviour for jobs already running; a pause cannot reverse an action already completed.

Maintain a set of representative evaluation cases, including awkward inputs and attempts to bypass instructions. Include cross-customer retrieval, revoked access, stale approvals and retries after an uncertain write. Measure factual accuracy, appropriate abstention, correct tool use and successful completion. Re-run those cases when prompts, tools, retrieval or models change. Code makes changes reviewable, but disciplined testing makes those changes useful.

Privacy and cybersecurity extend beyond the prompt

Map where information travels: source systems, tool services, the model provider, search indexes, logs, backups and approval screens. Each location introduces access and retention decisions.

Keep credentials in managed secret storage, enforce access in the application and underlying services, and separate customers or business units where required. Use the minimum authority each stage needs. A research stage may need read access; it does not automatically need the credentials used to publish the final result.

Treat retrieved content as data that may be untrusted. A web page or document can contain instructions intended to redirect an agent. Narrow tools, clear authority boundaries and validation before actions help limit the consequences, alongside appropriate prompt-injection testing.

Tracing helps explain failures and model behaviour. OpenAI's tracing documentation also describes control over sensitive-data capture. Plan that deliberately: a useful operational record may include IDs, timing and decision outcomes without copying an entire confidential document into every log.

Hosting your own harness does not necessarily keep inference inside your infrastructure. If the application calls a hosted model, selected data still leaves for that service. Review provider retention, training use, region and subcontractor arrangements against your requirements. Privacy comes from the whole data flow and its controls.

Why connected tools need boundaries

Security researcher Simon Willison describes the lethal trifecta: access to private data, exposure to untrusted content and a route for external communication. Together, those capabilities can let a malicious instruction in retrieved material cause a data leak.

In research published in August 2025, Zenity demonstrated a poisoned document redirecting ChatGPT to search connected Google Drive data for API keys and leak them through an image request. This was a research demonstration of the behaviour at that time, rather than evidence that every current connector has that specific flaw.

The design lesson applies to bespoke systems too. Reading outside documents should not automatically grant access to all private records or outbound services. You can separate a restricted reading stage from the service that sends an authorised reply. Control network access and output rendering as well as explicit send tools, because an external image request can also transmit information.

Code gives you a place to enforce those boundaries. It does not remove prompt injection or make an unrestricted agent safe by default.

Where shared AI work lives: portals, data and connectors

Once several people or workflows depend on AI, they need a shared record of the work. Nicola's team should be able to see which enquiries are waiting, who owns each one and which decisions have already been made, without hunting through someone else's chat history.

A portal gives shared AI work a useful home

Chat works well when a person directs the task and reads the result. A portal often helps when a team needs a queue, shared records, different permissions, approvals and visibility across many jobs.

The interface can show what the AI is doing, what evidence it found, which actions remain pending and who owns the next decision. It can also make review faster by showing the proposed change alongside the original record.

That does not require removing conversation. A portal can include a conversational interface while keeping the authoritative workflow state in the application. Different users may interact through chat, forms, dashboards or notifications, all referring to the same work item.

OpsUPLOOP illustrates the value of an operational foundation. Its outreach process builds a sourced prospect dossier, separates drafting and editing, and keeps human approval before letters are posted. It also exposes controlled MCP tools over business records. Those are concrete examples of research, AI work and review sharing one operating process. Its modules and integrations provide a starting point to assess for further workflows.

An existing product is useful only where it fits. Check its actual capabilities and extension needs against the proposed process. The value lies in reusing appropriate foundations while keeping the business rules explicit.

Your own connector lets chat become the front door

Here is where chat and coded software can reinforce each other. Once the enquiry, permissions and approval state live in your system, you can expose a controlled connector to that system.

Nicola might ask her assistant, “What is happening with Jo's enquiry?” The connector authenticates her, checks which records she may see and returns the status and relevant evidence. It need not give the assistant the entire customer database.

If she asks it to approve or send a response, the underlying service still checks her authority, the current record version and the workflow state. Those checks apply whether she uses the portal or chat. Identity must be established by the integration and server, rather than accepting the name the model supplies.

This is an important role for software as conversational interfaces become more capable. The interface can change while the authoritative record, operating rules and controls remain in the application. Chat becomes another useful route into the work.

When a data lake becomes useful

Some workflows need only a well-maintained operational database and a few document sources. Others draw on historical files, transactions, events and several business systems. A data lake may help organise that larger information landscape.

It needs ownership, definitions, lineage, quality checks and access rules. Without those, an agent can retrieve conflicting versions of the same fact and produce a confident answer from a poorly governed source.

Data engineering can expose approved datasets and retrieval services to the harness. The AI then works through controlled interfaces, rather than receiving unrestricted access to a warehouse of raw information.

Lake On Rails records dataset ownership, classification and retention, alongside procedures, approvals and an audit trail. It can read technical metadata from connected platforms without moving the contents of the datasets. This helps a business establish who owns information and which procedures govern its use. The harness still needs the appropriate data platform and retrieval implementation beneath that operating model.

A portal organises the work; governed data supports the decisions. Depending on the use case, you may benefit from one, both or neither. Start with the information and process requirements before choosing the components.

Design the information the AI receives

Giving an agent every available document can create noise, unnecessary cost and an unnecessarily large privacy exposure. Context design starts by deciding what information each stage needs.

Some questions need exact structured data. “How many open jobs does this customer have?” is normally a database query. Other questions need a search over meaning. “Have we solved a similar operational problem before?” may benefit from vector embeddings, which represent content numerically so a search can find semantically related material.

Retrieval design includes choosing source documents, extracting useful text, splitting it into sensible units and attaching metadata. You might record the owner, customer, date, document version and access classification alongside each chunk. Those fields help the application retrieve the right evidence and exclude material the user should not see.

A similarity score indicates relatedness. It does not establish truth, permission or current policy. A superseded document can be an excellent semantic match. Combine retrieval with access filtering, version handling and source references so the agent has useful evidence and the reviewer can inspect it.

Deletion and change matter too. If a source document is removed or its permissions change, the search index and cached results need an appropriate update process. An embedding pipeline is another copy of information to govern.

This is ordinary data engineering applied to AI. It remains important because better retrieval can improve the task without changing the model at all. It can also reduce how much information you need to send in each call.

Choose models and agents around measured jobs

It is tempting to draw a team of specialist agents before you have tested one. Start with the smallest design that handles the task, then add stages or specialists when they solve a demonstrated problem.

A straightforward pipeline can be easier to inspect than an agent deciding its own route. You might fetch records, call a model once to interpret them, validate the result and create a draft. More flexible orchestration becomes useful when the next step genuinely depends on what the agent discovers.

Two common patterns are handoffs and agents used as tools. A handoff transfers control to another agent. An agent used as a tool performs a bounded task and returns a result to its caller. The latter can help you give a specialist just the evidence it needs, although the actual context passed depends on your implementation.

Model choice can vary by stage. A demanding analysis may justify a more capable model, while a narrow classification task may perform well with a cheaper one. Test that on representative inputs. Lower token prices provide little value if the savings disappear into manual corrections.

Also test whether parallel execution helps. Independent research tasks may run concurrently. Two writes to the same record may need sequencing. More agents introduce more calls, coordination and failure paths, so measure the total result rather than treating a larger swarm as progress.

Your agentic code needs somewhere to run

A Python script in a development session becomes a service when people rely on it. It needs a runtime, deployment process, configuration, access control and someone responsible for keeping it working.

The OpenAI Agents SDK runs inside your application environment; it does not by itself host the business application. You might run Python workers in containers, behind an API and a job queue. TypeScript may suit a team already building its server-side application in Node.js. Choose around the team's skills, existing system and workload.

Cloud services can become part of the harness. On AWS, an illustrative arrangement might use S3 for documents, SQS for queued work and ECS on Fargate for workers. AWS publishes an asynchronous-processing pattern using SQS and Fargate. Azure Container Apps Jobs can run work triggered by queue messages; object storage can hold source files and outputs.

Other services might extract document text, process events or receive IoT telemetry. An AI workflow can interpret a maintenance note while ordinary code records the sensor reading and applies a defined threshold. There is no reason to make every stage agentic.

Choose the infrastructure for duration, volume, reliability and data requirements. A short request and a long research job may need different execution patterns. Avoid building a large platform for a small experiment, but give a shared workflow an operating environment that fits its responsibilities.

When building an AI workflow is worth the cost

Building introduces responsibilities as well as flexibility. You need developers, hosting, security, support and someone who owns the process. Changes to models, prompts, tools and business rules need appropriate testing. A coded workflow should not become dependent on one developer in the way the prototype depended on Nicola.

Changing software can take longer than editing a prompt, although you can make some instructions and rules configurable. Configuration still needs validation and versioning. Agree who handles incidents, how changes are deployed and what happens if the original supplier or developer is unavailable.

Keep a rare, low-risk task in chat when close supervision is sensible. Continue prototyping if you are still learning what good looks like. Systematise when the work is frequent, mistakes are expensive, several people depend on it, or it affects customers, records or money.

Buy when a supported product already runs the process well. Use a builder when it can express the necessary controls and integrations. Build where your particular rules, data or customer experience justify taking on the engineering. The first useful project can be one workflow across two or three systems.

Optimise the cost of a completed outcome

Token optimisation is part of harness design, alongside tool charges, infrastructure and human review. The useful unit is the cost of a successfully completed business task.

For illustration, suppose a workflow processes 500 cases a month. If model and tool charges average £0.20 per case, those charges total £100. If each case also needs three minutes of review at an assumed £30 an hour, review adds £750. These are invented planning figures, not a price or performance claim. They show why shaving a few tokens may matter less than making evidence easier to review.

Set budgets for calls, execution time, retries and external services. Decide what happens when a run reaches a limit: stop safely, create an exception or ask for approval to continue. A task should not be able to wander indefinitely because its completion criteria were vague.

Keep tool responses focused. Fetch only relevant fields, avoid repeatedly sending large documents and reuse trusted intermediate results when appropriate. Caching can help, but pricing and cache behaviour depend on the model and provider. Do not build the business case around an assumed universal discount.

Track quality and latency beside cost. A cheaper configuration may be too slow for a user waiting at a screen, while a background batch may tolerate a longer run. The right balance depends on how the result enters the business process.

In the illustration above, halving review time saves £375 a month. Eliminating the model and tool charges entirely would save £100. Better evidence and a clearer approval screen can therefore matter more than a cheaper model.

Compare those operating savings with the cost of building, adopting and maintaining the workflow. Include exception handling and unsuccessful runs. Use measured results to estimate payback; do not treat an impressive prototype as evidence of recurring savings.

What Gartner's forecasts suggest

In May 2026, Gartner predicted that by 2027, 40% of enterprises would demote or decommission autonomous AI agents because of governance gaps identified after production incidents. Its guidance distinguishes an agent's autonomy from the scope of access it receives and calls for controls proportionate to both.

That is a different forecast from the June 2025 prediction about cancellations of agentic AI projects, which cited costs, unclear value and inadequate risk controls. Neither statistic is an observed failure rate.

In April 2026, Gartner predicted that by 2028 over half of enterprises would stop paying for assistive intelligence and favour platforms committing to workflow results.

My interpretation is that buyers will increasingly judge AI by the finished job and the controls around it. A pre-built product may provide both, but these forecasts do not establish that every business should buy a package or commission bespoke code. They strengthen the case for choosing an operating process you can evaluate.

Choose one workflow and prove its value

Start by answering five questions:

1. Who owns the outcome? Name the person who defines success, handles exceptions and decides whether the result is good enough.
2. What can the workflow change? Separate reading, drafting and consequential actions. Identify approval requirements for each.
3. What evidence does it need? List the sources, access rules and freshness requirements, including what happens when information is missing.
4. How will it run? Establish volume, latency, scheduling, recovery and the interface people need.
5. What will prove value? Compare the existing process with representative trial results, including review effort and the full cost per completed task.

Measure the current process before the pilot: time spent, review effort, mistakes, exceptions and completed jobs. Agree the result that justifies continuing, who will judge it and when you will stop or change direction if the trial does not deliver.

An enquiry drafted at three in the morning and ready for a manager at nine can be useful even when the final decision remains human. Track what the manager changes and why. That evidence helps you improve the workflow and decide where further autonomy would be worthwhile.

As it becomes normal work, the process gains continuity: a new starter can follow the same standard, exceptions have an owner, and improvement does not depend on its original champion having a quiet afternoon. That is the business asset the harness helps you create.

How Scorchsoft helps turn experiments into operational workflows

At Scorchsoft, we build AI into products and business processes. Our AI agent harness development service covers process design, tools, retrieval, controls, evaluation and the surrounding application where needed.

My usual starting point for coded agent work is the Python OpenAI Agents SDK. TypeScript is another option, particularly where it fits an existing application. The language matters less than the decisions about authority, evidence, cost and the experience people have when using the result.

If you need help finding and proving the right improvement, our Managed AI & Automation Improvement Programme starts with an initial 90-day mandate. We find and baseline the opportunity, build and prepare the agreed workflow, then put it into controlled use and assess the evidence. Day 90 is a decision about what happens next, rather than an automatic continuation.

Bring one task that already shows promise, even if you currently supervise every step. We can assess which parts should stay flexible, which need formal controls and whether your existing tools already provide enough. You can get in touch to discuss it.

Keep experimenting with skills and connectors. When a task becomes something your business relies on, give the surrounding process the same attention you give the model. That is why I keep reaching for code.