- Services
SERVICES
- Platform
PLATFORM
- Solutions
AI AGENTS
LIFE SCIENCES AI
TECHNOLOGY
- Industries
INDUSTRIES
- Work
- About Us
CORPORATE
RESOURCES
- Contact us
Technical debt is the accumulated cost of implementation choices that were expedient at the time and make future change harder. AI-assisted development changes how it accumulates rather than whether it does, and the change is significant enough to warrant separate attention.
Three mechanisms are specific to AI assistance.
Volume outpacing review. Code can now be produced faster than it can be assessed with care. Where review depth falls to keep pace, decisions that would previously have been caught enter the codebase.
Pattern inconsistency. Generated code reflects general convention unless supplied with organisational context. Without it, a codebase accumulates several idioms for the same problem, each individually reasonable, collectively harder to maintain.
Comprehension debt. Code that nobody wrote is code that nobody has fully reasoned through. A team can find itself maintaining a system whose details were never held in anyone’s head, which is a real cost that shows up at the first difficult defect rather than at merge time.
Five practices, and the first is the one under most pressure.
Do not let review depth fall. Review capacity, not generation speed, is the real throughput limit. Teams that respond to faster generation by reviewing more superficially convert a productivity gain into a maintenance liability with a delayed cost.
Supply enterprise context so output is consistent by default. This is the highest leverage control, because it prevents inconsistency rather than detecting it afterwards. Standards, patterns, and reference implementations available to the AI produce output that already fits.
Automate the mechanical layer of review so human attention goes to design and correctness rather than to naming conventions and null checks.
Require understanding, not just approval. The engineer merging generated code should be able to explain what it does. This is the practice most quietly abandoned and the one that prevents comprehension debt.
Measure outcomes rather than activity. Lines generated and suggestions accepted say nothing about health. Defect escape rate, rework, change failure rate, and time to restore reveal whether speed is being converted into value or into debt.
The underlying point is that AI amplifies existing engineering disciplines in both directions. It is a multiplier on the practices already in place, not a substitute for them.
Wizr AI’s stated model is AI powered and human driven, with human engineers reviewing and approving every release. That positioning addresses the review depth question directly: acceleration is applied to the mechanical portion of engineering while the accountability for what ships stays with people.
The consistency mechanism is Glidepath’s context engineering from a single source of truth, a version-controlled repository of coding standards, architectures, and reusable artefacts with tested reference code, which is what makes generated output conform to one set of patterns rather than several. Built-in code, architecture, and compliance validation in the agent library handles the mechanical review layer, and Wizr AI reports a 60 percent reduction in compliance effort and issues from applying it continuously.
On measurement, Wizr AI reports a 40 to 50 percent developer productivity lift specifically with lower rework. Rework is an outcome measure rather than an activity measure, which is the right thing to track when assessing whether AI assistance is accumulating debt or avoiding it. Details are on the Glidepath AI SDLC page.
Ticket deflection is the proportion of inbound support contacts resolved without reaching a human agent. It is the most commonly cited metric in support automation and the most commonly misused.
The problem is that deflection counts contacts that did not reach an agent, and several very different outcomes satisfy that definition. The customer’s issue was solved. The customer found an article and left satisfied. The customer gave up. The customer went to another channel and now appears as a separate contact. The customer resolved nothing and posted publicly instead.
All five reduce agent contact volume. Only the first is a success. A deflection figure quoted without a resolution figure alongside it therefore says very little about whether the deployment worked.
Four measures together give an accurate picture where deflection alone does not.
Resolution rate, meaning contacts where the issue was actually solved, validated by the absence of a repeat contact on the same issue within a defined window.
Repeat contact rate, which is the single most useful check on a deflection claim. A deflection figure rising while repeat contacts rise means work is being displaced, not removed.
Cross channel leakage, tracking whether contacts deflected from one channel reappear in another. Chat deflection that increases call volume is not a saving.
Satisfaction on automated contacts specifically, separated from overall satisfaction, since aggregate scores hide a poor automated experience behind good human handling.
Deflection is also a poor optimisation target in isolation. A system optimised to avoid escalation will avoid it in cases where escalation was the correct action, which converts a support metric into a customer retention problem.
Wizr AI reports that a logistics SaaS customer achieved 43 percent ticket deflection alongside 50 percent faster response times. The pairing is worth noting, because response time is a customer experienced measure rather than a volume measure, and quoting the two together is a stronger claim than deflection alone.
Wizr AI’s customer support agents are designed to resolve rather than only divert, drawing on support centre content and past customer interactions and executing the actions a request implies through the platform’s integration layer. Complex cases escalate to human agents with context attached rather than being pushed back to self service.
Results of this kind depend heavily on knowledge base quality, contact mix, and integration depth in a given environment, so published figures should be treated as evidence that the approach works rather than as a forecast for a different operation.
A token is the unit of text an AI model processes. Models do not read characters or words directly; text is first broken into tokens, which are typically word fragments. Common words are usually a single token, while longer or unusual words split into several. As a rough guide for English, one token is around four characters, and a thousand tokens is roughly seven hundred and fifty words.
Tokenization is the process of performing that split, and each model family uses its own tokenizer, so the same text produces different token counts across providers.
Tokens matter to enterprises for three concrete reasons. They are the billing unit, so cost is calculated on tokens consumed for both input and output. They are the limit unit, since context windows are measured in tokens. And they are the latency unit, because generation time scales with tokens produced.
Token efficiency varies in ways that catch enterprises out at production volume.
Language matters substantially. English is the most token efficient language in most tokenizers, because they were trained predominantly on English text. The same content in many other languages consumes noticeably more tokens, which means a multilingual deployment costs more per interaction than a domestic pilot suggested.
Structured data is expensive. JSON, XML, and tables consume far more tokens than their information content implies, because syntax characters, repeated field names, and formatting all tokenize. Passing a large structured payload into context is a common and avoidable cost.
Identifiers fragment. Part numbers, ticket references, SKUs, and codes split into many tokens because they do not resemble natural language.
Repetition accumulates. System instructions and retrieved context are resent on every request in a conversation, so a long instruction block is paid for repeatedly rather than once.
The practical levers are retrieving fewer and better passages, trimming system instructions, converting structured payloads to compact representations before sending them, and caching stable content where the platform supports it.
Token consumption is the reason AI cost behaves unlike conventional software cost. A licence is fixed; token spend scales with usage, and therefore with success. A system that proves valuable is used more, which increases its cost, which is the opposite of the fixed cost curve most software budgeting assumes.
Three habits make this manageable. Measure cost per completed case rather than cost per token, since the token price is only meaningful once divided by outcomes. Model spend at projected production volume rather than pilot volume, because pilot traffic understates the eventual figure by an order of magnitude in most deployments. And attribute cost by use case, so an increase can be traced to a specific system rather than absorbed into a platform line item.
Agentic systems require particular attention here, since a single case may involve several model calls across a reasoning loop plus retrieval and retries, so cost per completed case can be many times the cost of a single response.
Tool use, also called function calling, is the mechanism by which an AI agent invokes external functions to retrieve information or take action. Each tool exposes one capability with defined inputs and outputs: query a database, call an API, search a knowledge base, post a transaction. The model decides which tool to call and with what arguments; the platform executes the call and returns the result.
Tool use is what separates an agent from a language model. Without tools, a model can only produce text from what it already knows. With tools, it can read the current state from enterprise systems and change that state. An agent’s practical reach is the sum of its tool library.
Tool definitions are also the primary permission boundary. An agent cannot perform an operation for which no tool exists, and cannot exceed the scope a tool exposes. Designing the tool set is therefore a security decision as much as a capability decision.
Tool design determines how often an agent gets things right, and a few principles hold consistently.
One capability per tool, with clear naming. The model selects tools from their descriptions, so ambiguous or overlapping definitions produce wrong selections. Precise, non overlapping tools reduce error more reliably than a better model does.
Narrow scope on write operations. A tool that updates one field on one record type is safer and easier to audit than a general update tool. Read and write access should be separated, and destructive operations kept behind approval.
Explicit, structured errors. An agent recovers from a failure it can interpret. A tool that returns an ambiguous error causes the agent to retry blindly or fabricate a result.
Validation independent of the model. Arguments should be checked against schema and business rules before execution, because the model’s reasoning is not a security control. This is the layer that limits the damage of a successful prompt injection.
The Wizr Enterprise AI Platform supplies a library of prebuilt tools with the ability to build custom tools for proprietary systems, connecting through the platform’s integration layer into existing enterprise applications and data sources.
The tool library is where Wizr AI’s functional agents get their reach. The finance and accounting agents operate against SAP, Oracle Fusion, Salesforce, and QuickBooks, cross referencing purchase orders, clearing reconciliation items within tolerance, and posting validated transactions back to the ERP. Dedicated solutions exist for Oracle ERP and Fusion and for Salesforce.
Because tool calls are the point where an agent changes enterprise state, Wizr AI logs them through the security and governance layer, and adversarial prompt testing forms part of its pre release testing and governance phase.
