A founder asks an AI tool to help onboard a new customer. It produces a checklist, drafts a welcome email and explains how to configure the account.
The founder still has to do the onboarding.
An autonomous agent should be able to take responsibility for the outcome: configure the account, move the necessary data, check that everything works, contact the customer and follow through when something needs fixing.
For developers building tools for small businesses, this is where autonomy becomes valuable. The opportunity is to give founders time back by creating software that can carry work through to completion, then keep handling that responsibility as the business changes.
That takes more than a capable model. It takes an environment in which the agent can act, remember, recover and improve.
Start with an ongoing responsibility
Most applications are designed around features. A useful autonomous agent can be designed around a job.
Consider a small software company whose founder personally handles every new customer setup. The work involves creating workspaces, importing records, configuring integrations and answering questions.
A practical role for an agent could be:
Own customer onboarding from signup to a working account. Adapt the setup to each customer’s requirements, resolve routine setup problems and keep the customer informed.
That gives the agent a destination without prescribing every step.
One customer may need a straightforward import. Another may send a spreadsheet with inconsistent column names. A third may need an integration connected before anything else can happen.
The agent needs room to choose its approach, inspect what happened and revise its plan. A rigid sequence of instructions will struggle with those differences.
For founders exploring existing products, the directory of most autonomous agents offers a starting point for finding agents organised around business needs. The useful question is which agent has the skills, tools and adaptability to take on a meaningful responsibility in that business.
Give the agent enough context to make decisions
A new team member needs to understand how the company works. An agent needs that context too.
For customer onboarding, useful context might include:
- What a successfully configured account looks like.
- Which settings customers can choose.
- How different subscription plans affect setup.
- Examples of previous imports and how problems were resolved.
- The company’s communication style.
- Which systems contain the latest customer information.
Developers should make this information accessible through maintained documents, structured records and tools that retrieve current facts.
Avoid putting the entire business into one enormous prompt. Prices, customer details and account states belong in sources the agent can consult when needed.
Separate relatively stable instructions from information that changes. “Explain setup problems in plain language” is a lasting preference. “This customer has already connected their accounting system” is a fact that should be checked against the account.
That separation helps the agent adapt without losing its understanding of the job.
Make execution durable
Real business work rarely fits inside a single uninterrupted model conversation.
An import may take time. A customer may reply tomorrow. An external service may become temporarily unavailable. The agent’s process may restart.
If progress disappears when the conversation ends, the founder becomes responsible for putting the job back together.
Store the state of the work outside the model’s context window. Useful records include the current objective, completed actions, unresolved problems, outstanding questions and the next event that should trigger progress.
For the onboarding agent, that might mean remembering that the workspace exists, the customer data has been imported and one integration is waiting for credentials.
When those credentials arrive, the agent should continue from there.
Tools should also make repeated execution manageable. Before creating another workspace or sending the same message again, the system should be able to determine whether the action already succeeded.
This is ordinary application engineering, but it has a direct effect on autonomy. Durable execution lets an agent keep working without requiring someone to reconstruct its history.
Build a feedback loop around the result
An agent needs evidence that its actions achieved their purpose.
An import tool returning “success” does not necessarily mean the customer’s account is ready. Records may be missing, fields may be mapped incorrectly or an integration may fail on its first real request.
Give the agent ways to inspect the result: query the account, compare record counts, exercise the integration and check whether the intended workflow actually works.
When something fails, the useful sequence is straightforward: investigate, change the approach, try again and verify.
IBM’s explanation of AI agents describes this combination of tool use, planning, feedback and iterative improvement. It is a useful foundation for thinking about agents as systems that act on their environment and adjust to what happens.
For a founder, the benefit is practical. Routine problems can be resolved within the work itself, instead of turning into another task in the founder’s inbox.
Let experience improve the next job
Self-improvement becomes useful when it produces a lasting change in how the agent works.
Suppose the onboarding agent discovers that a particular export format includes an extra header row. It identifies the issue, corrects the import and confirms that the records are complete.
If it encounters the same format next week, it should be able to reuse that knowledge.
Depending on the system, improvement might involve saving a procedure, updating a mapping rule, refining a reusable script or remembering a customer preference.
These are concrete forms of adaptation. They do not require the underlying model to retrain itself after every interaction.
Keep customer-specific information separate from generally useful lessons. One customer’s preferred setup should not silently become the default for everyone.
Changes to reusable procedures should also be traceable and reversible. That gives the agent room to improve its methods while making it possible to understand why its behaviour changed.
The goal is a worker that needs less repeated explanation as it gains experience.
Choose models and thinking effort around the work
The model matters, but the surrounding system determines what it can accomplish.
A strong model with poor tools and no persistent state may still require constant supervision. A well-built agent gives its model the information and capabilities needed to finish the job.
When choosing models, consider instruction following, tool use, reasoning, latency and cost together. The guide to choosing AI models for agents provides a useful introduction to those factors.
Different parts of a job may justify different amounts of computation.
Reading a known account status is usually straightforward. Diagnosing why two systems disagree about imported records may require more careful reasoning.
Where the model supports adjustable thinking effort, use it deliberately. More effort can help with difficult work, but it also consumes time and potentially more tokens. It does not guarantee a better result.
The reasoning-effort comparison charts help illustrate how results can change across effort settings. Treat those findings as evidence to investigate, rather than assuming one setting will be best for every workload.
For broader comparisons, the AI model comparison page brings model performance and pricing information together. Keeping those changing details in a live reference is more useful than designing a system around today’s winning model.
Build your application so model choices can evolve.
Measure the time the founder gets back
A cheap model call can become expensive when the founder has to inspect, repair and repeat the work.
Track the whole operation:
Cost per completed job = model usage + tool costs + retries + human time.
Then measure the outcome that motivated the project: how much attention the founder still needs to contribute.
For the onboarding example, useful measures include time to a working account, recurring setup failures and founder minutes spent per customer.
An agent may initially need context and corrections. As it retains useful knowledge and improves its procedures, repeated explanations and routine interventions should decline. If they do not, look for the missing capability: unclear instructions, weak tools, lost state or inadequate verification.
Autonomy becomes valuable when the founder can assign a responsibility and trust the system to keep making progress.
For developers, that is a worthwhile product goal: build an agent that understands the job, carries it through, learns from experience and makes the next working day easier for the person running the business.
Top comments (0)