DEV Community: Coryntas

Your Team Got Faster With AI. Why Is Your First Move a Layoff?

Vincent Tuan — Sat, 19 Sep 2026 15:30:10 +0000

Suppose your implementation team finally gets an AI workflow working. It produces useful first drafts of integrations, catches routine mistakes, and cuts down the time spent writing documentation. Engineers still review the output, but the improvement holds up after review.

At the next budget meeting, someone asks whether you still need the whole team.

You also have customers waiting to go live. A deal is stuck because nobody has time to build an integration. An experienced engineer keeps getting pulled into the same onboarding problem, which everyone agrees should have been fixed months ago.

I’d want to see what that team could deliver before cutting it.

Assume the AI works exactly as advertised. Why would a company with unfinished, valuable work make getting rid of the people who can now do it its first priority?

The salary savings are easier to put in a spreadsheet. I understand the attraction, especially when cash is tight. A CFO can estimate what removing two positions saves next quarter. The head of implementation has a harder argument: keep those people, give them different work, and expect more customers to get through onboarding.

One number looks solid. The other needs assumptions.

But the apparent certainty is misleading. The payroll reduction is measurable; the effect of losing those people is still a forecast. Someone is assuming the remaining team can absorb the exceptions, cover absences, and handle the next awkward customer without slowing delivery. Those assumptions deserve scrutiny too.

A growth proposal shouldn’t have to prove every future dollar while a cost-cutting proposal gets to ignore the work left behind.

Start with what actually became faster. If AI writes an integration in an afternoon, that’s useful. It doesn’t tell you whether the customer has agreed on what the integration should do.

In our example, sales promised to sync “active customers.” The customer’s finance team and account managers mean different things by active. An engineer has to find that out, get a decision, and keep it from becoming a production problem. Generating the connector was only part of the job.

Now suppose the AI gets good at flagging that ambiguity too. Fine. Give the engineer a better brief. There’s still a waiting customer whose project could move forward with the time saved.

The argument for keeping someone should survive improvements in the technology. If it depends entirely on AI continuing to make mistakes, it’s a weak argument.

The more interesting question is whether that employee can now take responsibility for work the company has been neglecting. That might mean handling another implementation, fixing the recurring onboarding problem, or turning a custom integration into something the next ten customers can use.

There is evidence that working with AI can improve performance, although it doesn’t settle staffing decisions. The 2023 NBER working paper Generative AI at Work reported roughly 14% more issues resolved per hour among customer support agents with AI assistance. Gains were concentrated among less experienced and lower-skilled workers, with minimal gains among the most experienced and highly skilled. Read the study.

The P&G experiment in The Cybernetic Teammate is uncomfortable for a simple “keep every team intact” argument: individuals with AI matched teams without AI on the innovation tasks studied. It also found that AI helped people produce proposals combining technical and commercial perspectives, and that human judgment retained value in selecting ideas. The results give leaders reasons to reconsider how work is divided. They don’t establish what staffing decision will grow your particular business. Read the study.

There’s a less comfortable part of this conversation that rarely fits into an AI productivity presentation.

Imagine you’re the employee who built the workflow. You tried the tools, figured out where they failed, and wrote down a process other people could use. Management celebrates it. Then a colleague loses their job because the team is now more efficient.

A few weeks later, management asks everyone to share more automation ideas.

You might have some hesitation.

You may still use AI. You might just stop advertising how much time it saves. Or avoid spending your own time teaching others a method whose reward appears to be another staffing review.

That is a plausible response to the incentives. If leadership wants people to expose inefficiencies and share what they know, it needs to think about what happens to the people who cooperate.

I wouldn’t solve this with a promise that nobody will ever lose a job. A company may not be able to keep it. I’d start with a narrower commitment people can evaluate: during a defined trial, use the released time to clear specific customer work, involve the team in choosing it, and judge the result before deciding what comes next.

Give people working hours to learn. Credit the employee who improves the shared process, including when someone else gets the resulting productivity gain. Be clear about which responsibilities are changing. Don’t announce that everyone is becoming more strategic and leave them with the same workload plus responsibility for checking AI output.

Back at our software company, this requires some fairly ordinary management work.

Pick the customers already waiting for implementation and confirm they’re ready to proceed. Assign owners. Agree on what has to be working for each customer to accept delivery. Reserve time for those projects by removing other commitments.

The AI can prepare project briefs from approved records, draft mappings, propose tests, and assemble documentation. Engineers can work through unresolved requirements with customers and check the parts where errors would be expensive. They should adjust that division as they learn what the system handles reliably.

A customer needs to be using the product sooner. If the team generates twice as many drafts and every draft waits a week for the same senior engineer, you’ve given that engineer a bigger queue.

So give the senior engineer time to improve the tests and review process. Have another employee turn the recurring onboarding issue into a documented fix. Let the people closest to the work tell you where the hours actually go; a manager’s guess from a ticket dashboard may miss most of the delay.

“We’ll use AI to grow” needs to get this specific.

When evaluating an enterprise AI provider such as Coryntas, bring the work your team keeps postponing: the integration nobody has time to build, the customers waiting for onboarding, the recurring problem everyone keeps fixing by hand. Ask what your existing team could get done with the right support.

Perhaps it can bring waiting customers live sooner, accept an integration-heavy deal it previously couldn’t service, or support additional customers without immediately hiring another implementation team.

These are different bets. Choose the one you can test against real demand.

For this example, a sixty-day trial could be enough to see whether comparable implementations are moving faster, how much correction they require, and whether the backlog is shrinking. It would not establish a long-term revenue effect by itself.

Count training, software, review, and maintenance costs. Check working hours too. If the team is finishing more because everyone works later, the experiment hasn’t shown what you think it has.

Finance belongs in that review. Ask it to help compare the contribution from additional work with the savings from a smaller team, over a period the company can actually afford.

And follow the result beyond engineering. Earlier delivery only brings revenue forward where the commercial terms make that true. An integration only helps win business if customers want it. A customer waiting on their own security review may remain blocked no matter how quickly your team writes code.

Keeping people is not automatically a growth strategy. Neither is buying them AI tools.

There are businesses with too little cash to wait for a redeployment experiment. There are teams whose workload has genuinely disappeared, with no useful adjacent work they can take on soon enough. Leaders have to make difficult decisions in those situations, and an article about augmentation shouldn’t pretend otherwise.

But that is a different situation from a company with demand it cannot serve, problems it cannot get around to fixing, and employees who have just found a way to free up some time.

In that company, I’d want the CEO to spend at least as much effort finding a productive use for those people as calculating the savings from removing them.

There is a hard decision hiding inside that request. Retaining the team means management has to choose work, clear obstacles, and take responsibility if the additional capacity produces little value. It is no longer enough to report that employees are using AI.

The implementation manager should come to the next budget meeting with named customers, delivery dates, the work being dropped, and an estimate of what completing those projects is worth. The CFO should challenge it. The team should have a chance to deliver it.

If the case falls apart, deal with that honestly.

But if the company can finally serve the customers it has kept waiting, why would making the team smaller be the obvious next move?

Your Team Has AI. Why Are You Still Chasing the Work?

Vincent Tuan — Fri, 18 Sep 2026 02:48:57 +0000

Consider a hypothetical deal at a B2B software company. The buyer sends a security questionnaire with 180 questions. Your team uses AI to find previous answers and prepare a draft. By the afternoon, most of the document is filled in.

Two days later, sales is still waiting to send it.

One answer describes a control that has changed. Another needs legal approval. A product question has been sitting in a shared channel because nobody knows who should respond.

You step in, find the right people, and chase the remaining decisions. Eventually, the approved version reaches the buyer.

The team saved time drafting. You still had to get the work finished.

If you are deciding where to invest in AI next, that remaining effort deserves a closer look.

The work after the draft still has a cost

Drafting is easy to demonstrate. Give a tool a document, watch it produce an answer, and compare that with the effort of writing from scratch.

Following the document through the business is less tidy. Someone has to establish which evidence is current, resolve uncertainty, find an approver, and make sure the final version goes to the right person.

If those steps caused the delay before AI arrived, a faster draft can leave the overall timeline largely unchanged.

It can also create a review queue. More material reaches the same small group of people, who now have to check it alongside their existing responsibilities. The work saved by one team becomes additional work for another.

Drafting assistance can still be valuable. But its local benefit tells you little about whether the company can handle more customer requests without adding coordination work.

For a founder, that difference shows up in the calendar: the same follow-ups, the same escalation meetings, the same requests to unblock something that looked almost done.

Define completion before expanding the rollout

For the questionnaire, an approved and delivered response is a useful finish line. A populated spreadsheet is an intermediate step.

That is the distinction behind Coryntas's Enterprise AI Has to Finish the Work: the business process defines completion, including the decisions and handoffs required to reach it.

In this example, current evidence must support the answers. Uncertain claims need review. An authorized person must approve what the company will tell the buyer. The team must retain the version it actually sent.

Each requirement should have an owner and a visible status. A message saying “legal is looking at it” leaves too much unresolved. Which person? What decision? By when? What happens if the deadline passes?

AI may help gather evidence, prepare answers, route questions, and track outstanding decisions. Those capabilities are useful when they advance an agreed process. An agent cannot settle an internal disagreement about who has authority simply by sending more reminders.

Before buying another tool, inspect a few recent questionnaires. Identify where they waited and what finally moved them forward. That gives you a concrete requirement for the next investment.

Give reviewers a decision they can actually make

Human review becomes expensive when the reviewer has to repeat the preparation.

“Please check this document” asks someone to discover every uncertainty themselves. A more useful handoff identifies the proposed answer, its supporting evidence, what remains unresolved, and the decision required.

The security owner can then assess a specific claim. Legal can review a specific commitment. Routine answers do not need to keep returning to the founder because one exceptional answer is blocked.

This division still leaves consequential decisions with people. The improvement is in how much searching, reconstruction, and chasing surrounds those decisions.

It also has costs. Connecting systems, keeping evidence current, and maintaining the workflow all require effort. An infrequent task may not justify extensive automation. Some cases will remain slow because the underlying question requires investigation.

Those limits should be visible before the rollout expands.

Check whether the process still needs rescuing

Compare the same kinds of cases before and after the change. Look at elapsed time from request to accepted delivery, the hours people spend reviewing and correcting, and how often a manager intervenes outside the planned approval process.

Include integration, maintenance, and exception handling when calculating the cost per accepted result. Keep quality alongside speed: sending an unsupported claim sooner would be a poor outcome.

Treat planned approval and unexpected intervention separately. A legal sign-off may be exactly how the workflow should operate. A founder repeatedly searching for the missing approver points to a problem worth fixing.

For your next operating review, bring one delayed task from the previous week. Trace what happened after the first AI output. Record where it waited, who intervened, and what they had to do.

Then choose one change and check whether comparable work gets through with less assistance.

Which recurring task still lands on your desk to unblock, even after your team started using AI?

What MCP Doesn't Solve

Vincent Tuan — Mon, 24 Aug 2026 07:42:00 +0000

Consider an illustrative employee-offboarding workflow. The HR system records that access should end at 17:00. At 15:30, the employee’s manager sends a message: “Their last meeting is done. Offboard them now.”

The agent finds the correct identity-management tool. Its arguments satisfy the input schema. The MCP server accepts its access token, and the target API is available.

None of that establishes whether the manager can change the effective termination time.

The connection may work exactly as designed while the resulting business action is premature, unauthorized, or blocked by information the tool call never examined.

MCP defines a useful tool boundary

The MCP tools specification gives applications a consistent way to discover and invoke capabilities.

A server publishes tool definitions containing names, descriptions, input schemas, and optional output schemas. A client discovers them through tools/list and invokes one through tools/call. The protocol also distinguishes malformed protocol requests from errors produced during tool execution.

This boundary solves a real interoperability problem. An application does not need a custom discovery mechanism for every database, document system, or internal API it connects to. Tool definitions give the model enough information to choose a capability and construct an argument payload.

The specification also assigns important security responsibilities. Servers must validate inputs, enforce access controls, rate-limit calls, and sanitize outputs. Clients should expose tool activity to users, validate results, apply timeouts, log usage, and request confirmation for sensitive operations.

These controls can establish that:

the requested tool exists;
the arguments have an acceptable shape;
the caller can reach the MCP server;
the server accepted or rejected the invocation; and
the result conforms to an expected structure.

The offboarding decision depends on additional facts. Which system controls the termination time? Can this manager modify it? Is there a legal hold? Has HR cancelled or delayed the event? Has another workflow already started the same task?

An input schema can require employee_id, effective_at, and reason. It cannot determine which source has authority over effective_at unless the surrounding system supplies and enforces that rule.

Transport authorization has a narrower job

The MCP authorization specification defines authorization for HTTP-based transports. It describes how a client discovers an authorization server, obtains an access token, and presents that token to a protected MCP resource.

That flow helps answer whether the client may make requests to the server with the granted scope. It does not contain the organization’s employment policy or decide whether this offboarding should happen at 15:30.

Production workflows often involve at least four identities:

The requester initiates the work. In this case, that may be the manager.
The actor is the workload identity calling the identity-management system.
The subject is the employee whose access will change.
The approver supplies authority for a decision the requester or actor cannot make alone.

Collapsing these roles creates misleading audit records. If the agent uses the manager’s token, the target system may record that the manager disabled the account even though an automated workflow selected the action and payload. If the agent uses a service account, the log may identify the technical actor while omitting who requested the change and which HR decision authorized it.

OAuth scopes can restrict what the actor is technically able to request. Workflow policy must still decide what this run may do to this subject at this time.

The distinction becomes more important when an MCP server calls another service. The official security guidance warns against token passthrough because it weakens audience restrictions and attribution. A separate downstream credential protects that boundary, but it still does not establish the business reason for using the credential.

The runtime needs a decision it can inspect

Before a consequential tool call, the runtime should be able to produce a compact record explaining why the action is currently permitted.

The following execution envelope is illustrative. It is not part of the MCP specification or a proposed extension to it.

task_id: OFF-2048
purpose: scheduled_employee_offboarding

requester: manager:1842
actor: workload:offboarding-agent-prod
subject: employee:7721

authoritative_event: hris:termination:99108
policy_version: access-offboarding@2026-07-15

decision: allow
allowed_action: identity.disable_sign_in
execute_after: 2026-08-24T17:00:00+07:00

approval_ref: hr-approval:5519
approval_payload_digest: sha256:84f2...

idempotency_key: OFF-2048:disable-sign-in

evidence_refs:
  - hris:employee:7721@version-44
  - idp:user:8fd2@observed-16:59:52

Each field closes a specific gap around the tool call.

authoritative_event ties the action to an HR record rather than the latest message in chat. policy_version preserves the rule used to reach the decision. execute_after prevents a valid future action from becoming an authorized immediate action. The approval digest binds the reviewer’s decision to a particular payload. The idempotency key gives the target service a way to recognize a repeated request.

Evidence references retain the records behind the decision without forcing every source document into the model context. They also give an operator something concrete to inspect when a run is challenged later.

The MCP request can carry some of these values as tool arguments. Their presence alone does not make them trustworthy. The runtime still needs to obtain them from authoritative systems, evaluate the applicable policy, and prevent the model or requester from substituting unsupported values.

Approval can expire before execution

Suppose HR approves the offboarding plan at 15:30 for execution at 17:00. At 16:45, the termination is delayed. At 16:50, legal places the employee’s documents on hold.

The earlier approval accurately described an earlier state. Reusing it without another check would authorize an action whose conditions have changed.

The runtime should revalidate the facts that materially affect the decision as close to execution as practical. For this workflow, that may include:

the current HR event and effective time;
the employee’s employment status;
active legal or security holds;
the validity of the approval;
the proposed action payload; and
the observed state of the target account.

This does not require a person to approve every directory read. Approval is more useful when it binds to the consequence: which account will change, when it will change, what related transfers will occur, and which exceptions remain unresolved.

If a material input changes, the runtime should invalidate the approval or request a narrower review. A generic confirmation for disable_user provides little evidence if the reviewer never saw the subject, effective time, source event, or dependent actions.

A timeout does not reveal whether the write happened

At 17:00, the agent calls disable_sign_in. The identity provider commits the change, but the response is lost before the MCP server receives it.

From the caller’s perspective, the request timed out. That observation does not prove failure.

Immediately retrying may be harmless if the operation is idempotent. The same approach can cause duplicate document transfers, repeated notifications, or multiple service-desk records when applied to other offboarding steps.

The tool boundary therefore needs more than a generic retry counter. A write-capable integration should expose enough execution information for the runtime to decide whether to retry, inspect, reconcile, or stop. Useful capabilities include:

a caller-supplied idempotency key;
a stable downstream operation identifier;
a status lookup independent of the original request;
a result that distinguishes rejected, committed, and unknown states; and
documented retry and compensation behavior.

MCP can transport these arguments and results. It cannot make HR, identity, storage, and ticketing systems participate in one atomic transaction.

The workflow must retain which actions were planned, approved, attempted, and observed as committed. Restarting the conversation is not a recovery strategy. A resumed run needs durable state that prevents completed writes from being replayed and directs uncertain writes into reconciliation.

Responsibility remains distributed

The MCP architecture gives the host responsibility for areas such as connection permissions, consent, and context aggregation. Servers expose focused capabilities, while clients maintain their connections to those servers.

A production workflow adds responsibilities across those components.

The host determines which servers and tools enter the model’s action surface. The workflow runtime retains task state, evaluates policy, binds approvals, and handles recovery. The MCP server validates requests and translates downstream failure details. The target system remains authoritative for whether its own records changed.

Logs from each component need shared identifiers. Otherwise, every system may contain an audit trail while no operator can reconstruct the complete action.

This machinery has a cost. Revalidation adds latency. Evidence retention introduces access-control and privacy obligations. Narrow tool exposure reduces flexibility. Reconciliation requires background processing and an owner for cases automation cannot resolve.

A read-only assistant that searches public documentation may not need the same controls as an agent that disables accounts. The required boundary should follow the consequence of the action and the difficulty of recovering from an incorrect result.

MCP makes tool integration more consistent. Production operation still depends on explicit authority, current evidence, durable workflow state, and known failure semantics around each call.

When one of your MCP writes times out, what record tells the runtime whether it should retry, reconcile, or stop?

This article was adapted for the DEV community from MCP Connects Tools. It Does Not Govern the Work., originally published by Coryntas.

Long-Running AI Agents Accumulate Context Debt

Vincent Tuan — Mon, 03 Aug 2026 07:46:55 +0000

An illustrative reporting agent prepares a monthly operating review. It queries finance, CRM, support, and the data warehouse; compares this month with prior periods; investigates material changes; drafts explanations; collects owner comments; and revises the report over several days.

By the third revision, its context contains raw query results, discarded hypotheses, repeated instructions, old owner comments, and the current draft. The most important correction—a finance owner rejecting the original revenue explanation—now competes with everything that came before it.

The agent has not run out of intelligence. It has accumulated context debt: temporary execution material has become permanent reasoning input.

The context window is a working surface, not the system of record

Keeping every intermediate result in the model context feels safe because nothing is lost. In practice, relevance declines as a run grows:

large tool responses consume tokens;
old instructions conflict with newer decisions;
repeated summaries introduce small distortions;
rejected hypotheses remain close to accepted findings; and
the current deliverable becomes harder to distinguish from earlier drafts.

A larger context window delays this problem. It does not define which state is authoritative, which evidence is recoverable, or which decisions should survive a restart.

A long-running workflow needs at least four storage roles.

1. Working context

The current objective, immediate constraints, selected evidence, and next executable step belong here. This set should be small enough that every item can affect the next decision.

2. Durable task state

Completed checkpoints, owners, approvals, deadlines, open exceptions, and permitted next actions should live outside the prompt. This state must survive model calls, worker restarts, and handoffs.

3. Evidence storage

Raw source results should be retained with stable identifiers, timestamps, and access controls. The agent can reload them when a later step needs inspection without injecting every record into every prompt.

4. Deliverable state

The current report, plan, ticket, or other business artifact needs its own version history. Reviewer changes should update this artifact without turning the entire conversation transcript into the only record of what changed.

Moving material out of the prompt is not deletion. It is putting information where the runtime can retrieve it deliberately.

Compaction should preserve decisions, not merely shorten text

A generic conversation summary may retain the topic while losing the operational fact that matters: who rejected an explanation, which source replaced it, and whether the correction applies to one metric or the entire report.

A useful checkpoint is structured. For example:

{
  "task_id": "monthly-review-2026-07",
  "objective": "Produce an approved operating review",
  "checkpoint": "finance-variance-reviewed",
  "accepted_findings": [
    {
      "metric": "net_revenue_retention",
      "explanation": "Two enterprise downgrades",
      "evidence_refs": ["warehouse:q_184", "crm:acct_72"]
    }
  ],
  "rejected_findings": [
    {
      "explanation": "FX movement",
      "rejected_by": "finance-owner",
      "decided_at": "2026-08-03T09:20:00Z"
    }
  ],
  "open_questions": ["Confirm support-cost allocation"],
  "allowed_next_actions": ["analyze_support_costs", "request_owner_review"]
}

The exact schema will vary. The important part is separating decisions from the tokens that produced them.

Each checkpoint should answer:

What remains in model context?
What moves to durable state?
Which raw evidence can be recovered later?
Which actions are valid from this state?

Compaction, subtask isolation, and progressively loaded instructions are mechanisms for enforcing those choices. They are not substitutes for a state model.

Subtasks need isolation and a shared contract

The reporting workflow can separate finance variance analysis, sales pipeline changes, and support-volume analysis. Each subtask receives only the systems, definitions, and period relevant to its work.

Isolation reduces interference, but it creates an integration problem. The coordinating agent cannot safely reconcile three polished narratives that use different definitions.

A shared result contract might require every subtask to return:

metric identifier and reporting period;
current and comparison values;
explanation and confidence;
authoritative source references;
unresolved issues; and
requested decisions or approvals.

This contract does more than improve formatting. It gives the coordinator a stable boundary for validation, comparison, and retry.

If one subtask fails, the runtime can rerun that unit without replaying the entire workflow. If a reviewer corrects a metric definition, the system can invalidate only the findings that depend on it.

Resuming is a first-class operation

A long-running agent should be tested from checkpoints, not only from the beginning.

At resume time, the runtime should be able to reconstruct:

the current objective and accepted deliverable version;
completed and pending steps;
active owners and deadlines;
the latest authoritative decisions;
evidence references needed for the next step; and
the permissions that are still valid.

This last item matters because authority can change while a workflow is paused. A task approved yesterday may require a new check before an agent performs the action today.

A resume test is therefore more than loading a saved prompt. It verifies that the workflow can rebuild the minimum trustworthy working set from durable state.

Context debt has an operating cost

External state introduces storage, retention, and access-control decisions. Compaction can omit a detail that later becomes important. Subtask isolation increases orchestration complexity. Reloading evidence can add latency.

Those are measurable tradeoffs. Useful signals include:

context size by workflow stage;
repeated retrieval of the same evidence;
compaction corrections by reviewers;
checkpoint resume failures;
stale decisions used after a restart;
evidence reload latency; and
cost per accepted deliverable.

Some work should pause instead of compacting. If reviewers fundamentally change the objective, starting a new version with an explicit handoff may be safer than asking the agent to reinterpret a long and contradictory history.

Finish with a record another run can trust

The completed report should retain its reporting period, metric definitions, reviewer decisions, evidence references, and unresolved caveats. Next month's agent can use the accepted artifact as a comparison without inheriting all of the execution debris that created it.

Context debt appears when a system confuses memory with accumulation. Long-running agents need a maintained working set and a durable operating record—not an endlessly growing prompt.

How are you separating working context from durable task state in your long-running agents?

This article was adapted for the DEV community from Long-Running Agents Accumulate Context Debt, originally published by Coryntas.

More Tools Can Make Your AI Agent Slower

Vincent Tuan — Sat, 01 Aug 2026 13:15:48 +0000

A renewal agent can call the CRM, email, calendar, support, document search, and contract systems. On its first run, it asks every system for everything related to one customer.

The result looks thorough: hundreds of CRM fields, years of ticket history, complete email threads, and the same contract attached to several messages. But the agent now has to spend time and tokens deciding which records matter before it can make progress on the renewal.

The agent is well connected. It is also slower, more expensive, and less certain.

Adding a tool expands what an agent can reach. It does not guarantee that the agent can select the right capability, retrieve a bounded result, or preserve enough of its execution budget to finish the task.

Tool schemas consume attention before the first call

An LLM needs the name, description, and input schema of each available tool before it can choose one. When several tools expose similar actions, selection becomes a routing problem.

Consider a broad interface like this:

{
  "name": "manage_account",
  "description": "Search, update, assign, add a note, change a stage, or create a task for an account",
  "parameters": {
    "account_id": "string",
    "operation": "string",
    "query": "string",
    "fields": "object",
    "assignee": "string",
    "stage": "string",
    "note": "string",
    "due_at": "string"
  }
}

It appears flexible, but every call asks the model to infer which combination of optional parameters represents the intended action. Validation and permissions must then account for every mode hidden behind the same interface.

A task-shaped read is less ambitious:

{
  "name": "get_renewal_record",
  "description": "Return the approved renewal view for one customer, including source timestamps",
  "parameters": {
    "customer_id": "string"
  }
}

The narrower tool is easier to select, permission, test, and recover. It may require additional orchestration steps, and it will not cover every future account workflow. That is a real tradeoff. The benefit is that each supported step carries less ambiguity.

Tool count therefore has two costs before execution begins:

every schema occupies context;
overlapping descriptions increase routing uncertainty.

Neither cost appears in a dashboard that reports only the number of connected systems.

Connectivity does not control the response shape

Suppose the CRM API returns 180 fields for an account. The renewal decision needs eight:

renewal date;
contract value;
account owner;
current stage;
product set;
open commercial risks;
last verified customer contact; and
source timestamps.

Passing all 180 fields to the model moves a data-selection problem into the most expensive part of the workflow. The same failure appears when an email connector returns complete message bodies instead of headers and short extracts, or when a document connector sends the same attachment once for every message that references it.

Each unnecessary value consumes something. It uses tokens when placed in model context, storage and transfer when retained outside it, and reasoning attention when the agent has to filter it.

The connector should return a task-shaped view:

{
  "customer_id": "cus_1842",
  "renewal_date": "2026-09-30",
  "contract_value": {
    "amount": 120000,
    "currency": "USD"
  },
  "account_owner_id": "usr_291",
  "open_risk_ids": ["risk_17"],
  "source_updated_at": "2026-07-29T08:42:10Z"
}

Raw records can remain available for inspection without being injected into every prompt. The agent can retrieve full email bodies or documents only after a bounded search identifies the relevant records.

Prompting the model to “focus on what matters” does not repair an oversized payload. By that point, the system has already paid to retrieve and expose the data.

MCP standardizes exchange, not business meaning

The Model Context Protocol gives compatible systems a common way to expose tools and context. That interface boundary is useful, but it cannot decide what a renewal agent needs from a CRM or which source should win when records disagree.

An MCP server can expose a technically valid tool that still returns the wrong slice of the system. It does not automatically answer questions such as:

Is this the current policy or an archived version?
Does the response include all pages?
Can this write be retried safely?
Do two records represent the same customer?
Is the caller allowed to see the underlying support incident?

Protocol compatibility and context quality are different properties. Standardizing the call does not remove the need to design the tool contract around the business task.

Pagination can make an incomplete result look complete

The agent asks for all open support tickets. The API returns 50 records and a continuation token.

If the tool output does not expose that token clearly—or its contract does not say when pagination is required—the first page can look like the complete result. The agent may produce a confident renewal summary while missing the ticket that explains the account risk.

“Fetch every page” is not always the right correction. An account with years of activity may have thousands of records. The workflow needs a completeness condition, such as:

retrieve all open tickets;
stop after the relevant date boundary;
continue until a known record is found; or
escalate when the result exceeds the reviewable limit.

The condition belongs in the workflow and tool contract. Otherwise, the model has to invent one at runtime.

Retries are part of the tool interface

Reads and writes fail differently.

If a CRM read times out, another attempt may be harmless. If a request to create a follow-up task times out after the server commits it, retrying can create a duplicate. Refusing to retry leaves the agent uncertain about whether the action happened.

A production write tool needs explicit answers:

Did the request fail before or after execution?
Does the operation accept an idempotency key?
Can the agent look up the committed action?
What evidence identifies a successful write?
Which errors require a person rather than another attempt?

These details rarely matter in a short demo. They matter as soon as an agent changes business state.

Measure accepted outcomes, not available tools

A useful evaluation starts with one outcome—for example, prepare a renewal brief with current commercial terms, unresolved support risks, source references, and an escalation when required evidence is missing.

Then measure the system that produces it:

latency per accepted brief;
tokens and tool calls per accepted brief;
incomplete or duplicated records;
unsafe or unnecessary retries;
reviewer corrections; and
cases escalated because a capability was intentionally unsupported.

Removing a broad tool may leave an edge case unavailable until the team designs a safer capability. A bounded agent that identifies that limit is often more dependable than one that guesses its way through a large tool catalog.

The practical question is not “How many systems can the agent call?” It is “Does each connection return the right information or perform the right action under conditions we can test?”

That is the distinction between an agent that looks capable in a tool list and one that can finish a workflow without losing control of cost, latency, or business state.

This article was adapted for the DEV community from More Tools Can Make an Agent Slower, originally published by Coryntas.