Build vs. Buy for Technical Support Investigations

A support team considering AI investigation has three choices: give employees Claude with MCP tools, build an internal agent, or buy a purpose-built system such as Decimal. All three can investigate code and logs. The meaningful differences emerge when a ticket changes, another teammate takes over, and someone has to keep the system working.

The first useful agent is the beginning of that responsibility. Shared evidence, automatic follow-through and improvement over time are capabilities to deliver and maintain. Decimal supplies the ticket investigation workflow with one charge through resolution. Building means deciding that your engineers should own and improve that product alongside your core product.

One ticket, three support teammates

Consider a fictional B2B data platform. A customer’s invoice sync has silently dropped records since a deployment. Retrying duplicates some invoices but leaves others missing. Only one region is affected. The timeline, people and diagnosis below are illustrative, not a customer benchmark.

First, consider individual Claude workflows. Maya handles triage with Opus and MCP tools for logs, code and account configuration. She traces requests through ingestion, a queue and the sync worker, compares successful and failed records, and checks the deployment diff. Several hypotheses remain. She asks for failed invoice IDs and leaves a summary before her shift ends.

Leo takes over when the IDs arrive. Maya’s summary lacks the exact queries, revisions and discarded hypotheses. His Opus session rereads the code and overlapping logs, then follows the new examples into retry handling. He finds that one path records the idempotency key before the write succeeds; another path changes that key on retry.

Priya, the support escalation lead, needs to establish which deployed workers use each path and whether replaying records is safe. She starts a third investigation, reconstructs the evidence and checks the regional configuration before escalating. Engineering still owns the fix and recovery plan. Three support employees have now commissioned substantial model work on one ticket.

New evidence and verification justify fresh work. Reconstructing earlier findings adds work without advancing the diagnosis. Opening a ticket costs no model tokens; asking Opus to investigate again does.

The internal agent starts with one useful run

This duplication is avoidable. Claude supports shared projects and knowledge, although chats remain private unless shared. Even individual workflows improve when teammates share evidence consistently. The limitation is relying on people to transfer the right state and initiate the next step.

An engineer can package the investigation into an internal agent: accept a ticket ID, fetch logs and code, reason about the failure, return a report. That is a useful first version. It standardizes the tools and instructions, and can make Maya’s initial investigation easier. It does not, by itself, settle what happens after she leaves.

When the invoice IDs arrive, someone must decide whether to run again and what state to carry forward. To automate that, the team needs ticket-event integration, durable findings and citations, rules for relevant new evidence, and a way to publish the latest result. A saved session is a building block; connecting it reliably to the evolving ticket is application work.

Once those requirements are solved, Leo can review the updated findings and Priya can escalate from the same evidence. A well-built agent can eliminate much of the duplicate investigation and manual handoff. Three employees need not mean three independent investigations. These are achievable capabilities, but they belong in the build’s scope and cost.

The Claude Agent SDK supplies primitives such as sessions, context management, permissions and hooks; managed runtimes can take on infrastructure. Your team integrates those primitives and owns the support-specific behavior. The question is who keeps improving that behavior after the prototype works.

What Decimal supplies through resolution

Decimal’s investigation is natively multi-turn. New ticket messages are automatically assessed for follow-up; relevant changes can trigger the next investigation without a teammate restarting it. Earlier responses and the conversation inform later turns. The ticket workspace retains investigations, sources and previous runs for the team to inspect.

In this case, the customer’s invoice IDs can trigger follow-up automatically. Leo reviews the updated findings; Priya carries the evidence into escalation. When engineering provides a fix, that update joins the same conversation. Processing follows configured eligibility and response limits. Continuity does not require every underlying lookup to be reused.

The public workflows make this concrete. Granola moved from a Cursor command that proposed hypotheses to Decimal investigations delivered in private Plain notes. Resilinc describes automatic follow-up as new information arrives and knowledge-article drafts after closure. These demonstrate deployed workflows; they are not benchmarks against a well-built internal agent.

Price the ticket, including repeated work

The billing route matters. Team, Pro and Max have included usage and optional paid credits. Current usage-based Enterprise charges seats plus tokens; legacy contracts differ. API builds are separately metered, with applicable credits reducing the bill. Don’t add a token charge to subscription usage that is already included.

An agentic investigation is a sequence of model calls: retrieve logs, inspect code, compare configurations, test another hypothesis. Count cumulative tokens, including context processed again and reasoning billed as output. The final answer shows only a fraction of that work.

For the individual-workflow scenario, model an expensive ticket: three investigations totaling 180 model calls. At standard Opus 5.5 API prices, the following cumulative usage costs $50. These are assumed totals across all three sessions, not one prompt, observed usage or an average ticket. The model already includes substantial cache reuse.

In a 20-person support team, if 500 distinct tickets a month reach this expensive profile, the modeled bill is $25,000 a month, or $300,000 if sustained for a year. Three investigations per ticket are already included. Headcount is not another multiplier: use affected tickets and the model calls actually made on each. Lighter cases cost less.

Estimate an internal agent from what it actually does. Without ticket-state reuse, it can repeat the same searches; with reuse, its work can narrow to the initial investigation, necessary follow-ups and evidence refreshes. Reusing findings can remove redundant reasoning steps, while caching lowers the price of repeated input. Do not automatically carry over the three-independent-investigations assumption. Measure actual calls and cache usage.

Its total ownership cost still includes variable inference, tool or runtime charges, initial engineering, ongoing maintenance and human review. Existing infrastructure can make the build attractive. Account for what you can reuse, then budget for the support-specific integration and upkeep that remain.

Decimal charges once per ticket to take it to resolution. The automatic follow-up as that ticket evolves belongs to the same ticket charge. Your model becomes billable tickets multiplied by the agreed ticket price, plus any contracted extras and remaining operating costs. Ticket volume still changes the monthly bill; the number of investigation turns on the path to resolution does not create separate ticket charges.

Caching, shared results and spending caps can materially reduce or contain the bill. Building ticket-level budgets, reuse and a fallback when a cap stops work is part of the build choice. A monthly spending ceiling alone does not get the customer to resolution.

The internal agent becomes a product you operate

Evidence must stay current and reusable

Maya’s deployment diff is useful only if it matches the worker serving the affected region. Preserved context needs provenance and freshness rules: what was observed, when, against which version, and what new evidence invalidates it. Anthropic’s context-engineering guidance describes selective retrieval and persistent notes for this kind of continuity. Storing a transcript alone does not establish which conclusions still hold.

When a log schema or helpdesk API changes, connectors and their interpretation need updating. After resolution, the retry diagnosis should help the next ticket. A saved knowledge article must distinguish a confirmed fix from a temporary workaround and exclude customer-specific data. Knowledge reuse needs review, versioning and retirement rules.

Permissions must survive every tool call

Priya needs enough access to establish whether replay is safe. That does not authorize the agent to replay invoices. Authentication, customer and tenant boundaries, and write permissions must hold across retrieval, stored state and tool execution. MCP’s security guidance covers token validation and scope minimization. The application still needs controls for unsafe tool requests, untrusted retrieved instructions, credential rotation and retention. Internal findings must stay out of customer-facing responses unless appropriate.

Decimal documents read-only investigation access, access controls and configurable retention. Buying still requires checking those controls against your requirements. You retain responsibility for the access you grant and the actions your team approves.

Ticket events must produce reliable updates

Suppose the customer adds evidence while a run is finishing, or a private note is written successfully but the response times out. A retry must not duplicate the note; a late result must not replace newer findings. The team needs concurrency rules, recoverable failures and idempotent writes. LangGraph’s durability guidance explains why side effects still need idempotency even with checkpointed execution. The framework supplies mechanisms; your application defines correct ticket behavior.

The agent must improve without regressing

Priya’s correction should become more than a thumbs-down. Capture the failed case, identify whether retrieval, reasoning or tool behavior caused it, make a targeted change, and check the result against earlier cases before release. That feedback-and-regression loop must continue as your product, documentation and tools change. Anthropic’s agent-evaluation guidance describes how evaluations expose behavioral changes before they reach users. A better model or prompt still needs those checks.

Trace tool failures and token usage back to tickets so a cheap-looking average cannot hide expensive outliers. Someone owns budgets, deployment, rollback and on-call recovery when models or integrations change. These responsibilities consume engineering capacity that could otherwise improve the product your customers buy.

Buying shifts implementation and operation of the investigation product to the vendor. It does not remove evaluation or vendor dependence: confirm service commitments, export options and incident ownership, and measure results on your tickets. The commercial advantage is getting an operating support workflow without maintaining a parallel product inside your engineering organization.

Choose what your team should own

Individual Claude workflows suit occasional investigations with an expert steering the work. Build an internal agent when proprietary workflows are a strategic advantage, unusual systems demand it, or existing infrastructure and a committed owner make the economics work. Budget for keeping it dependable and improving it after the first successful demo.

If complex investigations are routine and support infrastructure is not your product, choose Decimal. Shared evidence and automatic follow-up keep the case moving; one charge through resolution makes investigation pricing predictable per ticket. Your team owns the customer, product decisions and judgment. Decimal supplies the investigation workflow.

Bring one handoff-heavy ticket to a Decimal demo. Follow it from triage to escalation. The useful comparison is how much work the next teammate can continue from, and what your team must own to keep that working.