Direct answer: the first point of failure is almost never the language model itself, it is the integration with the existing information system. An agent that performs flawlessly on a clean test set fails in production because it meets an API that changed shape, an authentication token that expired, or a database that turned out less consistent than expected. The rest of this article walks through the five failure points we see most often on client engagements, in the order they tend to appear, and the checklist that catches most of them before launch.

An agent that clears every internal benchmark with a high score can still lose a meaningful share of its reliability in the first weeks of production, simply because a real environment never has the cleanliness of a test environment. That is not a failure of the model's intelligence. It is a failure of the engineering built around it.

The five failure points, in the order they appear

Each failure point tends to trigger the next one. Separating them helps you know where to look first once an agent starts behaving unexpectedly.

1. Integration with the information system

Most of an agent's value comes from acting on real systems: a CRM, an inbox, an ERP, a ticketing queue. These are also the least tested components, because they get built last. In production, an API changes its response format without notice, a token expires on a Sunday night, a rate limit trips during a traffic spike. Every integration adds one more failure mode to the full chain. According to a 2026 survey reported by Smartpoint, information-system integration is still cited by 46% of companies as the first obstacle to production, ahead of cost (43%) and data quality (42%). None of this shows up in a pilot built against a handful of hand-picked test accounts: it only surfaces once the agent meets the full variety of records a real information system accumulates over years.

2. Data quality and freshness

An agent connected to a stale knowledge base answers confidently from information that is simply wrong. This is the most dangerous failure mode because it produces no visible technical error: the agent keeps answering, just with outdated or incomplete facts. Hybrid search, combining keyword and vector retrieval, narrows the problem but never removes it if the source itself is not kept current. A common trap for smaller companies is indexing documentation once, at launch, and forgetting to resync it once the agent is live: within a few months the agent is confidently quoting pricing, deadlines or procedures that changed long ago.

3. A context window that overflows

An agent built on the ReAct pattern often chains five to fifteen cycles before delivering a result, each one adding text to the context window. Past a certain volume, the model loses track of instructions given early in the conversation, a phenomenon documented as "lost in the middle". The fix is not a bigger context window. It is reducing what gets injected into it: relevance upstream rather than volume. Summarising older turns instead of keeping them verbatim, and recalling only the facts relevant to the current step, prevents most of the drift seen on long conversations.

4. Missing execution guardrails

Without a queue, an agent collapses at the first traffic spike. Without a retry strategy, it gives up on a transient error that would have resolved itself thirty seconds later. Without cost controls, a poorly bounded loop can multiply model calls and produce an unexpected bill within hours. Queueing, retries and budget controls are usually the first pieces of infrastructure missing from a prototype that has never met production. They are also the least visible during a sales demo, since a demo by construction runs on low volume and a favourable set of cases, which is exactly what makes them easy to underestimate before the first real traffic spike hits.

5. A governance gap

When an agent gets something wrong, someone needs to be able to explain why and fix it. Without a decision log, and without a clearly named business owner, the error repeats itself because no one has the mandate to correct it. This is often the last failure point to surface, and the most expensive to retrofit, because it is organisational rather than technical. A team that discovers this gap after an incident loses valuable time reconstructing, after the fact, who should have signed off on what: better to settle it before the first deployment than during a crisis meeting.

The metrics that reveal a failure before the user does

Uptime and average latency, inherited from classic application monitoring, are not enough to watch an agent: it can respond fast, with no server error, and still produce a wrong result or the wrong action. Four complementary metrics matter more. The failure rate per tool call, tracked separately from overall uptime, reveals integrations degrading before a user ever complains. An abnormal retry rate signals a loop starting to misbehave. Cost per successful task, rather than total spend, catches drift before it shows up on the monthly bill. Finally, a small sample of responses reviewed by a human every week remains the only reliable way to catch a drift in correctness that technical metrics alone never capture. None of these four require expensive tooling to start: a spreadsheet updated weekly, populated from the agent's own logs, is enough for the first few months of production.

Symptom, root cause, fix

The table below lists the symptoms we see most often on engagements, matched to the fix that usually resolves the problem at the root rather than the surface.

The checklist before going to production

None of the following steps require a large team or a long timeline. Most take a day or two to put in place, and each one removes an entire category of the failures described above. In order, the steps that cut the most risk of a production failure.

1. Scope the task narrowly, with clear inputs and outputs, rather than leaving it open-ended.
2. Test against a sample of real production data, not only a clean synthetic set.
3. Put a queue and asynchronous processing in place before the first traffic spike, not after.
4. Define a retry strategy that distinguishes recoverable errors from permanent ones.
5. Set token quotas and automatic circuit breakers per user or per task.
6. Log every decision and every tool call, not only the errors.
7. Name a business owner for the agent, separate from the team that built it.
8. Plan a fallback to manual processing for when the agent steps outside its scope.

When an AI agent is not the right choice

An agent earns its keep when a task varies enough to require reasoning, while staying bounded enough to be verified. Outside that zone, it is usually not the right tool. A repetitive task with fixed rules and low volume is better solved with classic automation, cheaper to build and easier to audit. Conversely, a high-stakes decision that is hard to verify after the fact, or one bound by strict traceability requirements, keeps a human in the loop for longer than most product demos suggest. For a small accounting or legal practice, that means, concretely: automate the sorting and preparation of a file, but leave the final validation to a named person, rather than delegating the decision itself to the agent. The most reliable signal: if no one in the organisation can explain an automated decision after it happened, the agent is not ready for that scope, whatever it scored on a benchmark.

What we see on engagements

At Tesseract Studio, four products currently run in production, delivered by engineers who work embedded with the client rather than remotely against a fixed spec, the approach we detail in our article on the Forward Deployed Engineer. The pattern holds across engagements: failure points are almost never in the model chosen, but in the engineering around it, queues, logging, business ownership. That is also what separates a prototype that impresses in a demo from a system that still holds up a year later. Treating these five failure points as project risks, on the same footing as budget or deadline, rather than as technical details to settle later, directly changes the odds that the agent still holds up past the first few weeks. You can look at the detail of our work or browse all our articles on the topic.

A training crawler reads a page to fold it into the dataset behind a future model. An answer crawler reads a page in real time, the moment a user asks a question, to pull a citation into a generated response. In a robots.txt file, both announce themselves the same way, with a plain User-agent line. Economically, they could not be more different: blocking a training crawler protects content from future reuse, while blocking an answer crawler drops a site out of ChatGPT, Claude, or Perplexity answers immediately. Mixing the two up is the most common mistake we see when a company configures robots.txt for the first time.

The instinct, once a founder reads a headline about AI models scraping the open web, is to block anything that looks like an AI bot. That reaction genuinely protects content from being folded into a future model. It also strips away, in the same move, any chance of showing up in an answer generated the same day. The rest of this article works through the calculation crawler by crawler, so the two decisions do not get made at once by accident.

GPTBot, ClaudeBot, PerplexityBot: Who Does What

Each operator actually ships several crawlers with different jobs. Treating an operator as a single entity means blocking answer visibility while believing you are only limiting training.

One confusion is worth flagging on its own: Google-Extended is not Googlebot. Blocking Google-Extended has zero effect on classic indexing in Google Search, which stays entirely governed by Googlebot. A marketing lead who blocks Google-Extended believing it protects search rankings changes nothing about ranking, and only reduces the odds of showing up inside an AI-generated summary.

A Cloudflare network analysis published in August 2026 found that GPTBot is disallowed 2.33 times for every site that allows it, while OAI-SearchBot, the search-facing crawler from the same company, is allowed nearly as often as it is blocked. Sites that took the time to separate the two crawlers are not making the same tradeoff as the ones that block "OpenAI" as a single block.

For a small accounting firm in Geneva or an architecture practice in Lausanne, the difference plays out very concretely. A prospect asks ChatGPT for an accounting firm recommendation in Geneva: if GPTBot is blocked but OAI-SearchBot stays allowed, the page remains eligible for that answer. If both get blocked under one catch-all rule, the firm simply disappears from that conversation, and nobody inside the company notices, since few teams track AI citations the way they track search rankings.

The Real Trade-off: What Blocking Protects, What It Costs

What blocking genuinely protects

Blocking a training crawler limits how your text gets folded into a future language model. That matters for high-value editorial content, a proprietary dataset, or any sector where contractual confidentiality rules out external reuse. The protection is not retroactive, though: content already crawled before the block was set stays inside datasets that have already been assembled.

What blocking costs in AI visibility

Blocking an answer crawler, often out of caution by disallowing every user-agent containing "GPT" or "AI", mechanically removes a site from cited answers. For a company whose stated goal is to be found through answer engines, that choice works directly against the goal. Here is the standalone version worth quoting on its own: a training crawler builds a model, an answer crawler builds a citation; the first gets blocked to protect content, the second gets blocked at the price of the exact visibility a company is trying to earn.

A Five-Step Method

None of these steps require specialized tooling. A text editor, access to server logs, and a recurring calendar reminder cover the whole exercise for a company running a handful of key pages rather than a large content operation.

1. State the objective first: protect proprietary content, aim for citations in AI answers, or both, depending on the section of the site.
2. For each operator, separate the training crawler from the answer crawler instead of blocking the operator as a whole.
3. Write one explicit User-agent line per crawler in robots.txt, never a catch-all rule targeting anything containing "bot" or "AI".
4. Confirm in server logs that crawlers actually honor the published directives, rather than trusting the file alone.
5. Revisit the configuration every quarter: operators regularly ship new user-agents with different jobs attached.

A Working robots.txt Example

Here is a configuration that allows answer crawlers while blocking training crawlers, built for a company that wants AI answer visibility without handing over its entire content library to third-party model training:

User-agent: GPTBot
Disallow: /

User-agent: OAI-SearchBot
Allow: /

User-agent: ChatGPT-User
Allow: /

User-agent: ClaudeBot
Disallow: /

User-agent: Claude-User
Allow: /

User-agent: PerplexityBot
Allow: /

User-agent: Google-Extended
Disallow: /

This configuration is one specific trade-off, not a universal recommendation: a company selling high-value documentary content may prefer to block answer crawlers too, while a media site living off direct traffic may prefer to allow everything. Treat the block above as a starting point to edit, not a file to paste unchanged onto every domain.

Confirming the Directives Are Actually Followed

Major operators publicly commit to honoring robots.txt for their named crawlers, but that does not rule out a misconfiguration on the site side, or a third party spoofing a well-known user-agent string. Two checks usually cover it: reviewing server access logs to confirm the requesting IPs match the ranges published by the operator, and running the page through Google Search Console's URL inspection tool to confirm no accidental rule is blocking a legitimate crawler.

A third, less common check is to ask answer engines directly about your own sector, using a small, representative set of questions, and note whether the site shows up. That is the only check that measures the real effect of a robots.txt decision rather than its formal compliance. Even a simple monthly tracking sheet is enough to catch a regression after a configuration change.

When This Fine-Grained Calculation Is Not the Right Call

Two configuration mistakes show up most often once a company starts separating crawlers by hand. The first is copying a list found on a forum without checking the date: operators retire and rename user-agents, and a rule written against a two-year-old list can silently stop matching anything. The second is forgetting that a robots.txt directive is a request, not an enforcement mechanism; a crawler that ignores it entirely will not show up as an error anywhere, only as unexplained traffic in the logs. Both mistakes are reasons to keep the configuration simple rather than reasons to skip the exercise altogether.

Separating crawlers one by one takes ongoing maintenance and requires watching for new user-agents published by each operator. Two cases call for a more radical approach instead. First, a site handling data under contractual or regulatory confidentiality, such as healthcare, finance, or client records: blocking every AI crawler without distinction remains the safest position, even at the cost of total invisibility in AI answers. Second, an editorial site that lives off citation volume and holds no sensitive content: allowing everything, without bothering to separate training from answering, avoids maintenance that outweighs the stakes. Between these two extremes, most small and mid-sized companies are better served by the fine-grained calculation described here, neither the reflex block that sacrifices AI visibility for no measurable benefit, nor blanket access that gives away proprietary content for nothing in return.

One more factor shapes the decision: the size of the team that will maintain the configuration over time. A company without a dedicated technical lead is better off with a simple rule, revisited once a year with a partner's help, than with a ten-crawler matrix updated every time the news cycle shifts. The fine-grained method in this article is a tool, not an obligation: a simple configuration applied correctly beats a precise one that never gets updated.

A robots.txt setting is one technical lever among several: it does not replace the underlying work on page structure and verifiable data covered in our overview of the six levers behind visibility in AI answer engines. robots.txt and llms.txt answer two different questions: the first allows or blocks access, the second summarizes content for crawlers already let in. For a company that wants to know where it stands before adjusting its directives, the GEO Sprint starts from a concrete audit. All of the studio's articles on the topic stay listed on the blog.

Direct answer: an llms.txt is a text summary of your business, published at the root of your site, written for an AI assistant rather than a visitor. It takes about an hour to produce, costs nothing to host, and guarantees no citation in ChatGPT or Perplexity. The rest of this article explains why, and what matters more in its place.

An llms.txt file is a plain Markdown page, published at the root of a website (example.com/llms.txt), that summarises what a company does and points to its most important pages. Unlike a normal web page, it is written for an AI assistant rather than a browser: no layout, no navigation, no scripts, just structured text made of headings and lists of links.

The idea was proposed in 2024 by developer Jeremy Howard. The starting problem is simple: a language model has a limited context window, and a modern website carries too much noise (navigation, banners, scripts) for an assistant to easily pull out what matters in a single pass. llms.txt offers a shortcut: a one-sentence summary, followed by a curated list of the pages that actually count.

Why the format exists

Three answer engines dominate professional queries today: ChatGPT, Perplexity and Google's AI Overviews. Each sends its own crawler (GPTBot, PerplexityBot, Google-Extended) that browses the web in a more targeted, faster way than a traditional search engine. A well kept llms.txt gives them, in theory, a direct map of the pages worth prioritising instead of an entire site to crawl.

That is an attractive promise for a small business that has neither the time nor the budget for a full content strategy: one file, updated in a few minutes, meant to steer bots that otherwise know nothing about the rest of the site. Here is a definition that stands on its own, out of context: an llms.txt is a company summary written for a machine rather than a human, published at a fixed address, that AI assistants can consult before crawling the rest of the site.

The format has never been officially adopted by a major answer engine. OpenAI, Anthropic and Google have published no documentation confirming they rely on it to steer their crawlers. It remains a community convention, pushed more by third-party tools (generators, validators, CMS plugins) than by the companies that actually run the models.

llms.txt, robots.txt and sitemap.xml: three files, three jobs

The three files look alike (root of the site, plain text) but answer different questions. Mixing them up is the most common mistake among teams discovering the topic.

One point is worth clarifying right away, since it comes up often in client conversations: llms.txt blocks nothing. To stop a specific bot from training on your content, robots.txt is the file to edit, with a directive targeting that bot.

Writing an llms.txt in six steps

1. List the pages that actually matter. Between 10 and 30 pages: the homepage, the offer, case studies, cornerstone articles. Not the legal notice, not tag pages.
2. Write a one-sentence summary. This is the line most likely to be quoted if a model cites the file: it has to stand on its own, out of context.
3. Structure it in Markdown. A level-one heading with the company name, a blockquote for the summary, then level-two sections.
4. List links in a standard format. A dash, a Markdown link, a short description, one line per page, to keep it easy for a machine to parse.
5. Publish the file at the root. At the exact address yourdomain.com/llms.txt, as an absolute URL, never in a subfolder.
6. Keep it updated with every publication. A file referencing an article removed six months ago signals neglect, not credibility.

One technical point avoids a common disappointment: the file must stay reachable without authentication and without a redirect. An llms.txt served behind a cookie wall, or redirected to an HTML page, simply does not get read.

Checking whether the file is actually being read

Writing the file does not tell you whether it does anything. The most reliable method is also the simplest: check the server's access logs (or the host's, since both Vercel and Cloudflare expose them) and filter requests to /llms.txt by User-Agent header. Bots that identify themselves honestly do so clearly: GPTBot, ClaudeBot, PerplexityBot, Google-Extended. A request with no recognisable header, or coming from a residential IP address, is almost always a human audit or a third-party tool, not an AI assistant preparing an answer.

For most small business sites, this check takes one command line and a few minutes a month. It is a minimal habit, but far more honest than simply assuming the file is working.

A real example: the llms.txt of tesseractstudio.ch

Rather than staying theoretical, here is the practice. This site's llms.txt fits on one page: a one-sentence summary, three sections (what the studio does, why us, offers and pricing), the list of past projects with precise figures, then the list of blog posts, regenerated automatically with every publication. Nothing more. No decorative sections, no extended sales pitch: language models do not reward length, they look for factual density.

The blog section is generated by the build script at every new article, using a start and end marker in the source file. That is a technical detail, but it illustrates the core principle: an llms.txt that requires a manual update on every publication eventually stops being updated at all.

Mistakes that make an llms.txt useless

The most common one is copying the homepage's marketing copy, superlatives included. A language model handles superlatives ("leading", "best", "innovative") poorly: they carry no verifiable information. The second mistake is length: a file running to thousands of lines stops being a summary and becomes a site to crawl again, exactly what the format was meant to avoid. The third is abandonment: an llms.txt published once and never revisited loses its value within months, as the pages it lists change or disappear.

The fourth mistake, more subtle, is treating llms.txt as an access control mechanism. That is not its role: a bot that deliberately ignores the rules (which happens) is stopped by neither llms.txt nor robots.txt. Both files rely on the bot's voluntary cooperation, not on a technical block. For a restriction that actually holds, a server-side rule (application firewall, IP allow list) is the right tool, not a text file.

When not to bother with an llms.txt

This is the part most guides on the topic skip, and it deserves numbers rather than intuition. In May 2026, Ahrefs analysed the logs of 137,210 domains tracked by its analytics tool: 97 percent of published llms.txt files received not a single request that month. Of the roughly 38,000 domains with a valid file, only about 1,100 saw any visitor at all, human or bot. And among the few requests that did land, 77 percent came not from an AI tool but from SEO audit crawlers or generic bots: Slackbot alone requested llms.txt files more often than PerplexityBot did.

An independent study by Otterly.ai, run over 90 days across more than 62,100 AI bot visits on a test site, reaches the same conclusion: the llms.txt file received only 84 requests, three times fewer than an average content page, and no correlation was measured between its presence and an increase in citations. Google has publicly stated that it does not rely on the format.

The honest conclusion: if producing the file takes an hour and it updates itself, the opportunity cost is zero, and there is no reason not to publish it in case adoption grows. But commissioning a paid audit or a dedicated project purely for an llms.txt is not, today, a defensible investment. That is not where visibility in answer engines is decided.

The calculation changes with team size. A startup with a developer able to generate the file from existing content in an hour has no reason to skip it. A small business that would need to pay an agency by the day for the same task is better off spending that budget on one of the six levers that are actually correlated with measurable citations: page structure, structured data, or content that answers a question directly without a marketing detour. llms.txt is a checkbox, not a strategy.

What actually moves the needle for citations

llms.txt remains one building block among many, and a minor one. The levers that make a measurable difference to citability (page structure, factual density, structured data, server side rendering) are covered in our overview of the six levers of visibility in AI answer engines. For a Swiss SME that wants to know where it stands before spending time on this, the GEO Sprint starts from a concrete audit rather than an isolated text file. Every article the studio publishes on the topic is collected on the blog.

GEO, for Generative Engine Optimization, is the work of making a site readable and quotable by these answer engines. It does not replace SEO. It is a layer on top, with its own rules and its own measurements.

What GEO changes compared with SEO

SEO optimises for a ranking of pages. GEO optimises for passage extraction. That difference drives everything else.

A search engine returns a list and the user chooses. An answer engine composes text from fragments taken across several documents, then attributes sources. The unit that matters is no longer the page, it is the paragraph. An excellent article in which no paragraph stands on its own will be read by the machine and dropped at composition time.

Three practical consequences:

• Ranking first no longer guarantees a citation. Answer engines regularly reach outside the top three when a cleaner passage answers better.
• Traffic can fall while visibility rises. You are read and cited, but the user no longer needs to click.
• The brand becomes a measurable asset. Being named in an answer, even without a link, steers the rest of the conversation.

How an answer engine picks its sources

The exact mechanisms are not public and differ between engines. Three stages are nevertheless common to every retrieval-augmented architecture.

1. Access

The engine has to be able to read the page. That means its crawler is not blocked, the content is present in the served HTML, and the page responds quickly. Answer-engine crawlers are less patient than Googlebot and do not all execute JavaScript. A site whose content only appears after client-side hydration is, to them, an empty page.

2. Retrieval

The user question is turned into one or more queries, then passages are retrieved from an index. At this stage what gets compared is not your whole page but fragments. Hence the value of a structure where each section handles one question and only one.

3. Composition

The model writes the answer from the selected passages and attributes citations. It favours fragments that answer directly, carry a verifiable data point, and need no outside context to make sense.

The six levers that matter

Make content readable without JavaScript

This is the prerequisite, and it is where most sites disqualify themselves. Check what a crawler sees by fetching your page without running any script. If the text is not there, no other work will help.

Write self-contained passages

Every paragraph should survive extraction and still make sense alone. That means restating the subject instead of writing “it”, defining a term before using it, and putting the answer in the first sentence rather than the conclusion. A section heading phrased as a question, followed by a direct one or two sentence answer, is the format most often quoted.

Give verifiable data

Models favour fragments containing a number, a date, a name, a value. “The lead time is short” is not quotable. “The lead time is fourteen working days” is. If you state a figure, give its source and its date: that is what lets an engine reuse it without risk.

Structure your data

Schema.org markup will not magically place you in an answer, but it removes ambiguity: who publishes, when, on what topic, with what expertise. The useful types are few: Organization, Article or BlogPosting, FAQPage, Product, LocalBusiness. Link them through a stable identifier instead of redeclaring the company on every page.

Publish an llms.txt file

The /llms.txt file is a proposed convention, not an enforced standard, and adoption remains partial. The cost is nil and the value is real: it gives a plain-text description of what the company does, what it sells, and which pages matter. Treat it as an identity card written for a machine.

Decide which crawlers you allow

GPTBot, ClaudeBot, PerplexityBot, Google-Extended: each declares itself, and each can be allowed or refused in robots.txt. The calculation is simple. If your business sells advertising audience, blocking is defensible. If you sell a service and want clients, blocking means leaving the directory. For a services business, allowing is almost always right.

What to measure

GEO has a measurement problem: there is no Search Console equivalent for answer engines. Three indicators remain available without paid tooling.

The first is the most useful and the most tedious. It takes an hour to build: thirty questions a client would ask, asked monthly, in a spreadsheet. It is crude, and it is already more than most companies measure. If you would rather be handed the baseline, we produce it free of charge: see our packages.

Where to start

In order, because each step gates the next:

1. Check that your content is readable without JavaScript and that answer-engine crawlers are not blocked.
2. Ask your thirty questions and record who is cited today. That is your baseline.
3. Take the five pages that carry your offer and rewrite them as self-contained passages with dated data.
4. Add structured markup and the llms.txt file.
5. Ask the same questions again six weeks later.

None of this needs a marketing profile: these are technical decisions, taken by whoever writes the code. That is precisely the Forward Deployed Engineer role, which starts from the problem rather than the ticket.

None of this requires a rebuild. It requires precision, and some consistency in measurement. On a product still being built, these choices belong in the architecture rather than in a later pass, which is what we cover in our ninety-day delivery method.

The four engines do not behave the same

Talking about “answer engines” in the singular is convenient but misleading. The four main ones have different architectures, and what works on one does not transfer mechanically.

The practical consequence: classic SEO work remains essential for AI Overviews, while Perplexity and ChatGPT offer a way in for young or low-authority sites, provided the content is accessible and clean. That is where the opening sits for a smaller company starting out.

Five mistakes that cost you

Believing a block protects your content

Blocking GPTBot in robots.txt prevents crawling, not citation. An engine can still reuse your content if it finds it elsewhere, republished on a third-party site, without the link back to you. You lose attribution without gaining protection.

Confusing the crawling bot with the answering bot

At OpenAI, GPTBot feeds training, OAI-SearchBot serves search, and ChatGPT-User acts when a person explicitly asks to open a page. Blocking the first to keep training out while staying visible in search is coherent; blocking all three as a precaution removes you from the circuit entirely.

Optimising the home page rather than the answer pages

Answer engines rarely cite a home page, because it answers everything and therefore nothing. They cite the page that addresses the exact question asked. One page per question beats one page covering them all.

Burying the answer under the introduction

The usual narrative structure, context then development then conclusion, is exactly the inverse of what is needed. Put the answer in the first two sentences of the section, then expand. The extracted fragment will be the opening, not the closing.

Publishing numbers without a date or a source

A model choosing between two contradictory claims favours the one carrying a date and an origin. A bare figure is a figure nobody reuses, or worse, one that gets reused and attributed to someone else.

Building your question set

The measurement described above only works if the questions resemble what your clients actually ask. Here is the method we use, in about an hour.

1. Ten definition questions. What your business does, phrased by someone who does not know the industry vocabulary.
2. Ten comparison questions. Your solution against the alternatives, including the alternative of doing nothing.
3. Five selection questions. How to pick a supplier, on what criteria, at what price.
4. Five local questions. The same, with your city or region, if you serve a local market.

Each question goes to all four engines, and you record three things: are you cited, who is cited instead, and is the answer accurate. That third point is often the most instructive: a wrong answer about your company is fixed by publishing the correct information in an extractable format, not by complaining about it.

Repeat every two months. A single measurement says nothing; the gap between two measurements is what carries meaning.

Key points

• GEO optimises passage extraction, where SEO optimises page ranking. The unit that matters is the paragraph.
• A site whose content only appears after JavaScript runs is, to most answer-engine crawlers, an empty page.
• A fragment carrying a dated, sourced number gets reused more often than one describing the same thing with adjectives.
• There is no official console for measuring AI visibility. The workable method is a fixed question set asked at regular intervals.
• For a services business, blocking GPTBot or PerplexityBot means leaving the directory its prospects consult.

The role is now spreading beyond American software vendors, because AI has made the model viable at small scale. Here is what it actually covers, and when it fits a smaller company.

What a Forward Deployed Engineer does

An FDE writes code, but starts from the client’s problem rather than a ticket. A large share of the time goes into understanding the business: how the work is done today, where it jams, what data actually exists and in what condition.

The usual sequence has four steps:

1. Observe the process as practised, not as documented.
2. Build a narrow first version solving one specific case.
3. Put it in users’ hands within days, not months.
4. Fix based on real usage, then widen the scope.

What sets the profile apart is not technical skill. It is the refusal to separate the person who understands the problem from the person who writes the solution.

How it differs from a consultant and from an agency

The consultant produces analysis someone else must execute. The agency executes a spec someone else must have written correctly. The FDE removes the intermediary and absorbs the risk that the spec is wrong, which is the common case.

Why the model is becoming affordable now

Historically this model was expensive: a senior engineer, on site, for months. Only large organisations could fund it.

Two things changed.

The cost of a first version collapsed

Writing a working first version used to take weeks. With a coding assistant used seriously, that now takes days in many cases. It changes the nature of the conversation: you no longer discuss a mockup, you look at software running on the client’s data.

The cost of being wrong dropped

When a first version costs three weeks, you protect it, and you argue for months before writing it. When it costs three days, you throw it away without pain and start again. That shift is what makes the iterative model economically viable for a smaller company.

The consequence is counter-intuitive: AI did not make the developer redundant, it made the developer sitting with the client affordable. We put numbers on what that shift changes on a real project in what AI accelerates, and what it does not.

What it changes for a smaller company

Three differences show up within the first weeks.

The requirements document becomes optional. You no longer have to formalise upfront a need you only partly understand. The first version becomes the shared language, and it is what surfaces the real constraints.

Risk moves sides. A fixed price on outcome pushes the cost of estimation errors onto the supplier. It is also what forces that supplier to say no to requests that add nothing.

The rhythm becomes weekly. A weekly session with something visible replaces a monthly committee with slides. It is less comfortable, and far faster to correct.

When it is the wrong model

This way of working does not fit everything:

• When the need is fully stable and already specified, a traditional fixed-price supplier will cost less.
• When the main constraint is regulatory or contractual, the analysis phase does not compress, whatever the tooling.
• When an off-the-shelf product already covers eighty percent of the need, the right advice is to buy it, not rebuild it.
• When nobody on the client side can spend an hour a week on the project, the feedback loop never closes and the model loses its point.

That last point is the most underestimated. An FDE does not replace the availability of the business team: it depends on it.

A product shipped fast is worth little if nobody can find it. That is why visibility, and specifically GEO and citation by answer engines, is handled in the same motion as development. Our packages and prices are listed on the home page.

What a week looks like

The theoretical description shows little of the actual work. Here is the rhythm we hold on a typical engagement, and there is nothing exotic about it.

Monday, two hours with users. Not the decision-maker, the people doing the work. We watch over their shoulder while they handle a real case. That is where the parallel spreadsheets show up, the copy-pasting between two tools, the rules nobody wrote down. No scoping meeting surfaces that.

Tuesday and Wednesday, we build. The week's scope is deliberately small: one screen, one flow, one report. Enough to be usable, little enough to be thrown away without regret.

Thursday, it ships. To the real environment, with real data, reachable by the people we watched on Monday. It is the most important point of the week, and the one most projects push to the final quarter.

Friday, an hour of feedback. What got used, what got worked around, what is missing. The workaround is the most useful signal: it means the solution does not match the real work, and it is better learned in week two than in month six.

This cycle has a side effect we did not anticipate: user requests become sharper week after week, because people reason about something that exists rather than about an intention.

The skills that actually matter

The role is often framed as a senior engineering position. That holds for the technical part, but it is not where the difference is made.

Asking an open question

“What do you need?” produces a feature list, usually copied from an existing tool. “Show me how you do it today” produces a diagnosis. The first question costs months.

Being willing to throw away your own work

An engineer attached to their code slows the cycle, because they defend instead of listening. In this model part of the early work exists to learn and will be replaced. That is an accepted cost, not a failure.

Saying no with an argument

A fixed price on outcome forces you to refuse requests that add nothing, or you never ship. Refusing without explaining breaks the relationship; explaining the opportunity cost, by showing what would leave the scope in exchange, preserves it.

Knowing where your competence ends

On a regulated, accounting or medical subject, the engineer is not the expert and must not act like one. The role is then to translate faithfully a rule stated by someone else, and to have that translation validated.

How an engagement starts

We always follow the same order, because each step conditions the previous one.

1. A twenty-minute call. Context, pain, a quantified stake where possible. At the end we say whether the subject looks workable, and sometimes that it is not.
2. Half a day of observation. On site or over screen sharing, with the people concerned. This determines the real scope, often different from the announced one.
3. A quoted fixed price within forty-eight hours. One scope, one price, one date. No range, no day rates.
4. First release within one or two weeks. Narrow, real, usable.

If the second step reveals that an off-the-shelf product covers the need, we say so and the engagement stops there. It has happened, and it is the best possible use of half a day.

Key points

• A Forward Deployed Engineer starts from the observed business process, not a requirements document. The deliverable is software in production, not a recommendation.
• The model becomes affordable because a first version went from weeks to days, which makes being wrong cheap.
• Billing is fixed price per scope. Hourly billing penalises the fast supplier.
• The model fails when nobody on the client side can spend an hour a week on it: the feedback loop never closes.
• When the need is stable and already specified, a traditional fixed-price supplier costs less.

What “one hundred and six thousand lines” means

A line of code is not a unit of value. That volume includes database migrations, tests, configuration files and tool-generated code. A developer can triple the number by changing formatting style.

What the figure really conveys is the breadth of scope: authentication and role management, an onboarding journey with identity verification, electronic signature, dashboards, an admin back office, transactional messaging, and the deployment infrastructure around it. At a conventional pace, that scope is planned over six to nine months.

One more clarification, because honesty about numbers is part of the job: another of our projects shows a comparable volume, but it is mostly an off-the-shelf e-commerce theme, of which only a small share was written by us. We do not count those lines among our work.

What AI genuinely accelerates

The first draft

Writing a data access layer, a complete form with its validation, an integration test suite: this is known, repetitive work, and it is where the gain is clearest. What took a day takes an hour or two.

Crossing unfamiliar ground

Integrating an API you are discovering used to mean hours of documentation reading. The gain comes less from generated code than from the reduced time spent understanding.

The unglamorous work

Migrations, large-scale renames, dependency upgrades, writing the missing tests. These are low-decision, high-volume tasks, exactly the profile where assistance pays off most.

What AI does not accelerate

This is the part rarely written down, and it is what decides whether a project holds its dates.

• Deciding what to build. No assistant will tell you which product deserves to exist. That decision remains the main bottleneck.
• Getting business answers. If a functional question takes five days to answer, the project advances at five days per question, whatever the coding speed.
• External dependencies. A bank account, access to a regulated API, a legal sign-off: these delays do not compress, and they are the leading real cause of slippage.
• The quality of existing data. Taking over an inconsistent history demands analysis that nothing compresses.
• Trust. Software handling money or personal data requires checks that take the time they take.

Put differently: AI moved the bottleneck from writing to deciding. That is good news, provided the project is organised accordingly.

The method that makes the pace sustainable

Fixed price, never an hourly meter

Billing by the hour when you write quickly means penalising your own efficiency, and it rewards stretching engagements. A fixed price per scope aligns both sides: we gain from shipping fast and right, you get a budget known upfront.

A weekly session, with something running

No slides, no monthly committee. Every week, a deployed version you can use. That is what lets a scoping mistake be caught in week two rather than month four.

Scope is negotiable, the date is not

When something unexpected happens, the adjustment variable is the feature list, not the go-live date. That forces continuous triage, which is precisely the exercise missing from most projects that slip.

Visibility is built in, not bolted on

Server-side rendering, URL structure, structured data and crawler accessibility are architecture decisions. Adding them later costs several times as much, and it is the situation we meet most often with clients arriving with a product already built. Those choices are detailed in our guide to GEO.

What has to be true for it to work

Three conditions, and all three sit on the client side rather than the supplier side.

1. One decision-maker, available an hour a week. Not a committee. One person who can settle a question.
2. A narrow initial scope. A product that does one thing completely, rather than a full platform half finished.
3. Accepting that some work gets thrown away. Part of the first weeks exists to learn, and will be replaced. That is the price of speed, and it costs less than spending months building the wrong thing.

Without those three conditions the ninety-day pace is not reachable, and promising it would be dishonest.

This way of working has a name: it is the Forward Deployed Engineer role. Our packages and prices are listed on the home page.

How the ninety days actually break down

The breakdown often surprises, because it does not match the curve people imagine. Here is the order of magnitude observed on the investment platform, in weeks.

Two lessons. First, the functional core, the part everyone imagines as long, takes about a third of the time. Second, the final third, handling edge cases and security, is as long as the core, and it is the one systematically underestimated in quotes.

The risk peak is not at the start but around week eight, when external dependencies land. That is where an access that does not arrive pushes everything downstream, with no amount of code able to help.

What we threw away

On this project three pieces of work were written and then replaced. Mentioning them is not misplaced modesty: it is the mechanism of the model, and the scrap rate is part of the quoted cost.

• A first onboarding journey, designed from what the business described. Contact with the first users showed that two of its five steps had no reason to exist. Three days of work, replaced in one.
• A full dashboard, of which three indicators out of eight were never opened. We removed them rather than maintain them.
• An abstraction layer built to support several signature providers, when only one was retained. A textbook case of premature generalisation, and the only one of the three that could have been avoided.

Across the project this scrap amounts to roughly one week out of thirteen. That is the price of speed, and it stays far below the cost of spending months methodically building the wrong thing.

What the fixed price implies on our side

Quoting a firm price on a partly known scope means accepting three constraints, which it is fair to state.

We turn some projects down. When the request arrives as a frozen forty-page specification, the model does not apply and a traditional supplier will do better. We say so rather than take the engagement.

We price in the unexpected. A fixed price with no margin is a fixed price that gets renegotiated, which amounts to billing by the day with an added round of conflict. The margin is included from the start, and that is also why our price is not the lowest on the market.

We arbitrate continuously. At constant scope and fixed date, every addition means a removal. That trade-off happens at the weekly session, with the decision-maker, never at the end of the project.

What we do not promise

A product shipped in ninety days is not a finished product. It is a product in production, in use, whose next steps are decided on real usage rather than assumptions. The difference is considerable and rarely stated.

Nor do we promise the pace transfers to a project where a regulator, a banking partner or a legal department sets its own calendar. In those cases the constraint is no longer how fast software gets written, and claiming otherwise would be selling you a deadline we do not control.

Key points

• A line of code is not a unit of value. What a code volume measures is the breadth of scope covered.
• AI accelerates the first draft, unfamiliar APIs and repetitive work. It accelerates neither decisions, nor external dependencies, nor the quality of existing data.
• The bottleneck moved from writing to deciding. What needs reorganising is the project, not just the tooling.
• Scope is the adjustment variable, never the go-live date.
• Three client-side conditions: one decision-maker available an hour a week, a narrow initial scope, and accepting that some early work gets thrown away.