Claude Partner Network · Internal Agentic Platform & AI Product Build
Built in your repositories, in your cloud account, with the architecture decisions written down as records rather than held in our heads.
Pexon builds internal agentic AI platforms on Claude: identity layer, tool layer, memory, orchestration, evaluation and cost attribution. The model is the one layer you rent, and the six around it decide whether agents reach production. The same architecture serves a customer-facing product, with a different risk owner.
Why prototypes stop
None of these is a model problem, and that is the point of the list. Every one of them is a layer that was not built because the prototype did not need it, and every one of them is discovered at the review rather than at the demo.
01 · Identity
The prototype authenticates once, with broad rights, and every user's request inherits them. It works perfectly and it cannot pass a review, because the honest answer to "whose permissions was this read under" is "ours".
02 · Tools
Tool definitions, retries and error shapes written per agent. The third one means three places to change when an entitlement rule changes, and no single place to see what the fleet can do.
03 · Evaluation
The system is judged by whether the demo went well. With no eval suite and no threshold somebody signed, there is no defensible moment to say this is ready, and no way to notice the day a model update makes it worse.
04 · Cost
Calls carry no team key, so spend arrives as a single number with no team behind it. By the time anyone wants it split, six months of history cannot be attributed retrospectively.
The architecture
The model is a dependency you buy at a published price and can change. Everything that decides whether agents reach production is in the six layers around it, and all six stay yours.
01
The request carries the caller, not a service account. Tool calls are authorised against the same groups that govern the underlying system, so the assistant inherits a permission model you already audit instead of introducing a second one.
02
One registry, one error shape, one retry policy. Tools are named operations against real systems rather than a shell the model may use freely, which is what makes the audit trail readable afterwards.
03
What the agent may remember, for how long, and whose data it is. Retrieval is filtered at query time by the caller's entitlements rather than after the fact, because post-filtering a result set still sent the data to the model.
04
Where control flow lives when a task needs several steps or several agents. Usually smaller than expected: a loop, a plan step and a stopping condition cover most of what gets called multi-agent.
05
A suite with a pass threshold somebody signed, run on every model and prompt change. This is the layer that turns "it seems better" into a release decision, and the one most often skipped because nothing breaks visibly without it.
06
Every call tagged with a team or project key from day one, and spend reportable per team at month end. Built first, not last, because attribution cannot be applied to history that was never tagged.
Two buyers
What we build
A platform build is a pod engagement rather than a fixed-price sprint, because the scope is set by how many of the six layers already exist. Most companies have one and a half of them.
The executable part
This is the check we run before any agentic system goes live, and it is three steps because it has to be runnable by somebody who did not build it.
# The rule every tool call is built to satisfy
#
# An agent may read nothing its caller could not read unaided.
#
# WRONG — the agent holds the rights. Works in the demo, fails the review:
# client = ErpClient(token=SERVICE_ACCOUNT_TOKEN) # broad, shared, unattributable
# rows = client.query(user_question) # whose permissions? ours.
#
# RIGHT — the call carries the caller, and the source system decides:
# caller = verify(request.headers["Authorization"]) # the user's own OIDC token
# client = ErpClient(on_behalf_of=caller) # exchanged, not substituted
# rows = client.query(user_question) # the ERP applies ITS rules
#
# The test that this is real, and the one to run before go-live:
# 1. Pick a document user A may read and user B may not.
# 2. Ask the agent for it as B, through the product, not through a test harness.
# 3. The answer must be a refusal, and the refusal must appear in the audit log
# with B's identity on it.
#
# If step 3 produces the document, you do not have an identity layer. You have a
# service account with a chat interface in front of it.Token exchange rather than token substitution is the part that is easy to get subtly wrong: an exchanged token still represents the user, a substituted one represents the application and silently widens the blast radius.
When we are the wrong choice
If you need one agent for one task and you are confident there will not be a second, do not buy a platform. Hard-code it, ship it, and accept that the fourth one will be expensive — that is a reasonable trade and we will say so. If your bottleneck is that the data is unreachable rather than that the agent is unbuilt, the platform will not help and the data layer work comes first. And if you want a vendor to own the system permanently, we are a poor fit by design: this is built to be handed over, which costs more up front than a managed product and is worth less to you if you never intend to take it.
Pexon Group is a Certified partner in Anthropic's Claude Partner Network (Services Track), granted on 1 October 2026. This site is published by PEXON ROMANIA S.R.L., a separate legal entity in the same group, and the party you contract with here.
Because the second agent is where the cost appears. One agent can hard-code its credentials, its tools and its evaluation, and it will work. The third one written that way means three places to change when an entitlement rule changes, three audit trails in different shapes, and no way to answer which team the tokens belong to. The platform is what makes agent number four cheap.
Whatever survives your constraints, and we will argue for the smallest thing that does. A large share of what gets called an agent framework is a loop, a tool registry and a retry policy, and writing those three yourself is often less work than adopting a dependency that owns your control flow. Where a framework earns its place, we say which part of it is doing the earning.
Between the user and the tool call, and it is the layer most prototypes do not have. The rule we build to is that an agent may read nothing its caller could not read unaided, which means the tool call carries the caller's identity rather than a service account with broad rights. Service-account agents are the single most common reason a working prototype fails a security review.
Tenancy and evaluation thresholds, mostly. Internally a wrong answer embarrasses you; externally it is a support ticket at best and a disclosure at worst, so the isolation between tenants has to be structural rather than a filter in a prompt, and the eval suite needs a pass bar someone signed off. The six layers are the same ones.
Attribution before optimisation. Every call carries a team or project key from the first day, so spend is attributable per team at the end of month one rather than discovered as a single invoice line in month six. Caching and routing come after that, because you cannot rightsize a workload you cannot yet split by owner.
That is the intended ending, and it is worth agreeing at the start rather than at handover. The platform is built in your repositories, in your cloud account, with the architecture decisions written down as records rather than held in our heads. Where a team wants us to keep running it, that is the managed operations engagement and a separate decision.
Next step
Thirty minutes with the architect who would run the build. The most useful thing you can arrive with is a prototype that works and could not be approved, because the reason is almost always one of the six layers and it is usually the first.