AI agent development.

A chatbot produces an answer, an AI agent produces a result. Technically put: the chatbot runs a single model call and returns text. The agent runs in a loop — it plans a step, calls a tool, reads what comes back, judges whether the goal is reached, and starts again. That loop runs until the result is there, an approval is pending, or a stop condition takes effect.

Three capabilities make the difference concrete. First, tools: the agent may call functions you give it — a search in the document store, a query in the ERP, the creation of a record, the sending of a draft. The model decides which tool makes sense when; it may only execute what you have enabled. Second, multi-step work: a task like "check this supplier invoice against the order and report deviations" consists of four to eight sub-steps that build on each other. Third, state: the agent remembers within a run what it has already checked, and across runs how comparable cases were decided.

The price difference sits in exactly the same place. A chatbot on your documents is a manageable project. An agent touches permissions, data quality, approval paths and questions of liability — that is software development with an AI component, not the configuration of a tool. The conceptual basis is set out in our glossary entry on AI agents; how operational automation follows from it is described in our practice article on AI agents in business automation.

An agent fit for use has five building blocks: model, tools, context, state and approvals. Leave one of them out and you get either a toy or a liability.

• The model makes the decisions and writes the output. It is interchangeable and should stay that way: models get retired, cheaper or better, and an agent nailed to exactly one model becomes a problem in year two. We therefore wrap model access behind a layer of our own.
• The tools are the functions the agent may call, each with a clear description, fixed parameters and minimal permissions. A tool is not full database access but "find customer by company identification number" or "add a note to case X". The narrower the cut, the more reliable the agent.
• The context is the knowledge the agent fetches at runtime: manuals, price lists, earlier cases, guidelines. Technically that usually happens through RAG — the model searches your sources and takes only the matching excerpts into the call. That keeps costs down and answers current.
• The state records where the agent stands in a task, what it has tried and what failed. Without state it repeats mistakes; without a log there is no way to reconstruct afterwards why it did something. Both belong in from the start, not in version two.
• The approvals separate reading from writing. Reading steps run without a query. Anything that goes outside, moves money or changes data is produced as a proposal and waits for a human confirmation — human-in-the-loop, in the jargon.

On top of that comes the work on the instructions themselves. An agent is steered through its system instruction, its tool descriptions and its stop rules; that is not busywork but the part that decides reliability. The fundamentals sit in the glossary entry on prompt engineering. And if the agent is to operate not only your systems but your own website, that website needs machine-readable entry points — described under agent-ready website and at length in our guide to WebMCP and agent-ready websites.

Suitable tasks are those that occur frequently, arrive unstructured, can be answered from a clear data source, and whose result a person can check in under a minute. Those four conditions together are the best filter we know — take one away and the project gets expensive.

• Pre-qualifying enquiries: the agent reads incoming emails and forms, maps them to a service, pulls in the customer history, spots missing details and drafts the follow-up question. Approved by the office, sent with one click.
• Checking receipts against orders: invoice as a PDF, order in the ERP, delivery note in the inbox. The agent pulls the line items together, flags deviations in quantity, price and terms and writes a review note. The booking is still done by a person.
• Support triage: incoming tickets are classified, linked to the matching passage in the manual and given a draft reply. Simple cases go out after approval, complex ones reach the specialist team with the groundwork done.
• Tenders and market watching: the agent searches defined sources for relevant tenders or price changes, filters by your criteria and produces a weekly shortlist with a reason for each hit.
• Maintaining master data: address changes, duplicate records, missing industry or company identification details are detected, enriched and offered as a change proposal for confirmation — rather than as a silent bulk import.
• Recurring summaries: collect figures from several sources, compare against the previous month, explain anomalies in three sentences. That does not replace the analysis, but it does replace the two hours of copying that come before it.

What is deliberately missing from the list are tasks with legal or financial finality: payroll runs, tax filings, signing contracts, medical assessments. There the review effort exceeds the saving, and one step that runs through wrongly costs more than the agent saves in a year. To work out which of these fields is worth anything in your business, a consulting day is the cheaper entry point than a development project — that is what AI consulting is for.

A first agent fit for production is built with us as a prototype for idea validation from CHF 10'000; on top come running model and operating costs that follow the number of runs. The prototype covers a single, cleanly scoped use case with real tool integration, approval logic, logging and a test run on real data. It is deliberately built as a basis for a decision: afterwards you know whether the build-out is worth it — rather than finding out after an annual budget.

The running costs are the point most offers keep quiet about. An agent run does not consist of one model call but of as many as the task has steps, and every call carries the history so far along with it. Costs therefore scale with the number of steps and the length of the context carried, not with the number of messages. An agent that solves a task in three steps is in practice many times cheaper than one that feels its way through twelve — and that is a question of scoping, not of the model price.

We therefore build in three limits from the start: a step limit per run, a daily cost ceiling and caching for content that does not change. We pass the provider's model costs through transparently rather than folding them into a flat rate, because they shift with every change of model. What operation will cost you per month we estimate before the start from your expected volume and then measure in trial operation. Larger undertakings, where the agent becomes part of a portal or an existing application, run with us as a complex web solution; websites and portals themselves range from CHF 3'000 to CHF 25'000 depending on scope.

From the first conversation to trial operation typically takes four to eight weeks, spread across five steps. The schedule almost always hangs on data access, not on the model.

• 1. Scoping (week 1): we write the use case up as a process, with trigger, data sources, decision points, approval stages and stop conditions. At the end there is one sentence describing what the agent does — if it does not fit in one sentence, it is scoped too broadly.
• 2. Access and tools (weeks 2 to 3): interfaces, technical user, permissions per tool, test data. This step decides the deadline. If a system vendor has to be involved, we say so in advance and not in week five.
• 3. Agent loop and evaluation set (weeks 3 to 5): instructions, tool descriptions, state handling — and alongside them an evaluation set of 30 to 60 real cases with known correct outcomes. Without that set no statement about reliability is possible, and every later change becomes a blind flight.
• 4. Shadow operation (weeks 5 to 7): the agent runs alongside real cases but decides nothing. Its proposal is held against the actual human decision. Only when the hit rate is stable over several weeks does one action go live — the most harmless one first.
• 5. Handover and operation: documentation of tools and permissions, log access for your team, a fallback plan for an outage at the model provider, and a fixed rhythm for checking the evaluation set and the costs.

If you want to start a step earlier, begin with a consulting day: collect use cases, score them and try two of them out. That day usually reveals whether an agent is needed at all — or whether a simpler automation would do. We describe that route under AI automation for SMEs and digital consulting.

The three real risks are error propagation across several steps, uncontrolled cost per run, and writing actions without approval. Two more are often overlooked: instructions smuggled into foreign content, and the duty to disclose in customer contact.

• Error propagation. The reliability of a multi-step process is the product of its individual steps, not their average. At 95 per cent per step, a chain of ten steps arrives at roughly 60 per cent overall; at 90 per cent it is around 35 per cent. So: keep chains short, insert a check after critical steps, define stop conditions and measure every change against the evaluation set.
• Cost per run. An agent that goes off the rails does not produce an error message, it produces an invoice. A step limit, a daily ceiling, caching and an alert on unusually long runs belong in the first version, not the third.
• Writing actions. Anything that goes outside, moves money or changes data needs a human approval, a complete log and a way back. We enable writing tools on a test tenant first as a matter of principle, and in production one at a time — never as a package.
• Smuggled instructions. An agent that reads foreign content — emails, PDF attachments, web pages — also reads text written as if it were an instruction to it. The countermeasures are minimal tool permissions, an allowlist of permitted sources, no credentials in the context, and the rule that a writing action may never follow directly from text that was read.
• Disclosure and law. If the agent interacts directly with people, the transparency duties of the EU AI Act under Article 50 apply and have been enforced since 2 August 2026: the system has to be recognisable as AI, and synthetic content has to be machine-readably marked. Breaches can cost up to 15 million euros or three per cent of worldwide annual turnover. The duties for high-risk systems were postponed to December 2027 with the Digital Omnibus. Switzerland has no overarching AI act; data protection law applies technology-neutrally, and the Federal Office of Justice is preparing a consultation draft by the end of 2026.

An agent is not worth it when the task occurs rarely, when the path is always the same, or when the result has to be correct without any way of checking it. We draw that boundary in the first conversation, even when it argues against the larger commission.

• Too few cases. A task that comes up ten times a month and takes ten minutes each does not justify a development project. The rule of thumb: without several hundred cases a month or a high value per case, the benefit stays theoretical.
• The path is fixed anyway. Where input and process are structured, a script or a workflow automation is faster, cheaper and more reliable. Putting a language model in between only adds cost and fuzziness.
• No checkable output. If nobody can tell quickly whether the result is right, the safety net is missing. Then you first need a definition of what "correct" means — otherwise you are automating an error at scale.
• The data is not there. If the knowledge sits only in people's heads, in paper files or in scanned images without text recognition, preparing the data is the actual project. That is doable, but it is not the same budget.
• Nobody takes on the operation. An agent is not a piece of furniture. Models change, interfaces change, your processes change. If nobody in the house is named to look at logs and grant approvals, the agent is switched off within six months.
• It is really about information. If your people only need to find the right passage in a manual or a contract quickly, you need a search across your documents — a RAG assistant, not an agent. That is a considerably smaller project.

We have no publicly showable agent reference so far, and we do not invent one. That is the honest starting position, and it belongs on this page because we would name it in any first conversation anyway.

What we can show are the building blocks an agent project consists of. For a tax advisory offering in Zurich we built a web application in which customers choose a package, create an account, upload documents and book an appointment — meaning state handling, file handling, user permissions and a continuous process rather than a brochure website. Alongside that come bespoke calculators and configurators, in which input is processed rule-based into a definite result. Exactly those parts — data access, rule set, approval, logging — make up the bulk of the work in an agent project; the language model is the smaller share.

We are a small team with our own development capability, working out of the studio at Gustav-Maurer-Strasse 23 in Zollikon. In Zollikon, Küsnacht, Zurich and the immediately neighbouring municipalities we work on site; the rest of Switzerland we support remotely. If you are looking for an agency to sell you a finished agent platform, we are the wrong address. If you want one scoped use case built properly — including the uncomfortable questions about permissions, costs and liability — it fits. For projects with an agency connection in the city there is the page on the AI agency in Zurich, and if the task turns out to be answering rather than acting, the boundary is drawn under chatbot development.