- Services
SERVICES
- AI Assembly
AI ASSEMBLY
- Solutions
AI AGENTS
PHARMA & 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 integrations with enterprise systems and data sources. 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 supported by the underlying AI infrastructure.
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 underlying AI system 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.
Wizr AI provides agents with prebuilt tools and supports custom integrations with proprietary systems, connecting AI agents to 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 its security and governance capabilities, and adversarial prompt testing forms part of its pre release testing and governance phase.
The transformer is the neural network architecture underlying virtually every modern language model. Introduced in 2017, it replaced earlier sequential architectures and is the reason large language models became practical.
Its central mechanism is attention, which allows the model to weigh the relevance of every part of its input when processing any given part. Reading a sentence, the model can connect a pronoun to a noun mentioned much earlier, because attention operates across the whole input rather than propagating information step by step.
The practical breakthrough was parallelism. Earlier architectures processed text sequentially, one token after another, which made training on very large datasets prohibitively slow. Transformers process the whole input simultaneously, which is what allowed training at the scale that produced current model capability.
Several properties enterprises encounter daily follow directly from how transformers work.
Context windows exist because attention has a cost. Attention compares every part of the input against every other part, so computation grows sharply with input length. The context window is where that cost is capped, which is why it is a bounded resource rather than an arbitrary product decision.
Position in the input matters. Attention is distributed unevenly across long inputs, which is why material at the beginning and end of a large context is used more reliably than material buried in the middle. This is the architectural reason context engineering affects accuracy.
Tokens are the unit because the architecture processes tokens. Billing, limits, and latency are all measured in tokens because that is what the model actually consumes.
Output is generated one token at a time. Even though input is processed in parallel, generation is sequential, which is why response latency scales with output length and why instructing concise responses genuinely reduces wait time.
Understanding this is not required to deploy enterprise AI, but it explains why several of the practical constraints exist rather than leaving them as arbitrary rules.
Rarely, and the reasons are worth being clear about.
Architecture is almost uniform across current models. Essentially every production language model an enterprise can buy is transformer based, so architecture is not a differentiator between options being evaluated. Comparing models on measured performance for the specific task, on cost at production volume, on latency, and on deployment and sovereignty constraints is considerably more informative.
Architecture is also not stable enough to build commitments on. Variants and successors appear regularly, and an architecture that is dominant today may not be in three years. This is a direct argument for keeping the model layer replaceable, so that application logic, retrieval, tools, and governance are unaffected when the underlying model changes.
Where the architecture does matter is in explaining constraints rather than choosing products. Context limits, token based pricing, uneven attention across long inputs, and latency scaling with output length all follow from it, and teams that understand why those constraints exist design around them better than teams treating them as arbitrary.
