There is a sentence the engineering recruitment market has been quietly avoiding.
The sentence is: the model is the easy part.
It is unfashionable because the entire AI hiring discourse — Forward Deployed Engineer roles at Anthropic and OpenAI, Applied AI Engineer roles at Scale, Solutions Engineer roles at Databricks, every Staff-grade title with "AI" in the name — pretends the job is the technical thing on the marketing page. The model. The prompt. The agent loop.
It is not.
The job is the wiring. The integration into the SSO. The audit trail formatted for the regulator's auditing tool. The secrets rotation that does not break the eval suite at 03:00. The change-data-capture stream that backfills the vector store every twelve hours without taking down the source database. The broken SOAP service the auth team forgot existed but the agent needs to call.
This work has a name. It is called glue code — a term that has carried mild contempt for thirty years in engineering circles, and that has quietly become the single most valuable skill on the market in 2026.
What "glue code" means in the LLM context
For most of software history, glue code was the small, embarrassing scripts at the edges of a system — the bits you wrote because the database driver did not quite return what the API contract said it would. The work was real, but the cultural framing was that real engineers built libraries and frameworks; glue code was what you did at the end of a sprint when there was nothing else to do.
The economics of LLM deployment inverted this completely.
A modern enterprise AI system has — at a rough count, depending on the institution — between fifteen and forty distinct integration surfaces. Each one is a glue point. Each one carries its own auth flow, its own failure mode, its own audit obligation, its own legacy quirks. The model lives in one of those surfaces. The other thirty-nine are the difference between a working production system and a ZIP file on someone's laptop.
A non-exhaustive list, in the order they tend to show up in the project:
1. Identity
The agent has to act as someone. That someone is in the enterprise's IAM directory, which in most regulated institutions is one of three things:
- IAM Identity Center on top of Active Directory
- Okta or Azure AD with custom SAML to legacy systems
- A homegrown LDAP that predates anyone still on the team
The agent's auth token has to be derived from the human's auth token, on every call, with the original principal preserved in the audit trail. SAML assertions in flight, JWT scoping, role-chain assumption, and the agent's permissions modeled as a strict subset of the human's — never a superset, ever, under any circumstance. We laid out the architecture in Designing Strict RBAC for Enterprise Knowledge Bases, but the deeper truth is that every other integration in the system inherits from this one. Get it wrong and nothing downstream is salvageable.
2. Source-of-truth extraction
The corpus is rarely a clean directory of PDFs. In the real institutions where AI is meant to land, it is:
- A SharePoint instance with three years of orphaned permissions
- An IBM DB2 database where the schema is a thirty-year-old artefact of someone's RPG report layout
- An Oracle Forms application with screen-scrape as the only documented access pattern
- A monthly Excel drop into S3 that the compliance team treats as the canonical record
- A SOAP service the auth team forgot existed but which holds the only authoritative role mapping
Every one of these needs a structured ingest pipeline — incremental, idempotent, restartable, and quiet enough to not page the on-call. The pipeline is glue code. There is no library that does it for you because the shape of each enterprise's mess is unique.
3. The audit trail
Every model invocation must produce a forensic record that an auditor — internal or regulator — can read in six months and reconstruct exactly what happened. Prompt, response, model version, retrieval evidence, user principal, time, and any tool calls the agent executed.
This is not a Datadog dashboard. This is a structured event stream, written to an object-locked bucket, with retention policies enforced by KMS keys nobody on the engineering team has access to. The events have to round-trip back into the eval pipeline so regressions get caught against real production traffic. They have to feed the compliance team's existing reporting tooling without requiring that team to learn a new vendor.
The infrastructure for this is described in The Blueprint for Air-Gapped LLM Deployments on AWS Bedrock — CloudTrail data events on every Bedrock invocation, model invocation logs to a dedicated audit bucket. But the architecture is the easy part. The glue is fitting it into the institution's existing audit workflows without requiring six committees' approval.
4. Secrets and credentials
The agent has secrets — API keys to internal services, KMS key IDs, SSM parameter paths, OAuth client credentials. These rotate. Sometimes automatically, sometimes on a security incident, sometimes because some unrelated team rotated a shared key and nobody told us.
The rotation flow has to be:
- Picked up by the agent on the next invocation without restart
- Not invalidate any in-flight conversation state
- Not break the eval suite that was running at the time of the rotation
- Logged, so when something does go wrong, the timing of the rotation correlates with the failure signal
There is a Kubernetes-native answer for this, an AWS-native answer for this, and a homegrown-Vault answer for this. There is also the institution's existing answer for this, which is usually a fourth thing and which is non-negotiable. The glue is making the agent operate inside that fourth thing without rewriting the institution's secrets posture.
5. The escalation surface
When the agent hits an edge case — low confidence on a retrieval, an action that requires elevated permission, a prompt that triggers a guardrail — it has to get out of the way. The escalation goes to a human. Which human? Through which queue? With which context payload? Reaching them how — Slack, Teams, an internal ticketing system, an email?
This is glue code. It is also the single most important determinant of whether the deployment survives the first quarter of production use. We covered the pattern in agent action approval gates but the harder problem is the wiring into the institution's existing ticket flow — which is some version of ServiceNow or Jira with a custom workflow nobody documented in 2017.
6. The cost telemetry
Token spend, model-tier distribution, cache hit rates, prompt-length percentiles, per-tenant spend. All of it has to feed back to the finance team in the format they recognise — usually monthly, usually tied to a specific cost centre, usually with a budget alert wired to the same Slack channel that pages the on-call.
The first time the finance team sees a model bill they did not expect, the project is on probation. The second time, the project is dead. Cost telemetry is the seatbelt — invisible right up until it is the only thing that matters.
The architecture for the model-tier cascade and prompt caching is in Cost Optimization on Amazon Bedrock, but the visibility layer — the part the CFO sees — is glue code, written specifically for the institution's existing finance reporting cadence.
The profile this work selects for
Read those six integration surfaces. None of them are model engineering. None of them are AI research. None of them appear on the slides at a major conference. All of them are the actual job.
The engineer who can survive this work shares a specific profile:
- Senior enough to have lived through legacy integration before — knows that SOAP and SAML and X.509 and an Oracle Forms screen-scrape are all real and all still in production at most institutions worth deploying to
- Has built and shipped end-to-end systems, not just prototypes — has seen what happens when a vector store ingest fails at 02:00 on a public holiday
- Can hold a context-shifting conversation with a regulator's auditor in the morning, a CISO in the afternoon, and a junior backend engineer in the evening — without losing the institutional politics of any of the three
- Reads logs the way some people read literary criticism — alert to the unstated, watching for what should be there and is not
- Does not need the dignity of complex problems. Will write the ten-line glue script that integrates the legacy ticket system, ship it, and move on. The script will still be running in three years.
This profile has a market name now — Forward Deployed Engineer, Applied AI Engineer, Customer-Facing Solutions Architect — but the work is older than those labels. It is the work of any engineer who has shipped serious software into a serious institution.
The reason it has become the most-bid-on profile in 2026 is straightforward. The model is, finally, good enough that the integration is the project. The bottleneck moved.
What this teaches us about enterprise scaling
There are two ways to read this piece.
The first is as career advice: glue code is no longer the low-prestige work it was framed as for thirty years. The engineers who lean into the integration surface, the auth flows, the audit trails, the secrets rotation, the legacy database extraction — those are the engineers companies are paying staff-tier compensation for in 2026.
The second is as architecture advice. If you are scoping an enterprise AI deployment and the technical conversation in the room is about the model and the prompt, you are scoping the wrong thing. The technical conversation should be about the six surfaces above. The model is a procurement decision. The integration is the project.
If the integration is not on the architecture diagram, the project is in the ninety-five percent. We wrote about why ninety-five percent of enterprise AI pilots fail at the deployment phase — this piece is the granular version of the same diagnosis, told from the perspective of the engineer who has to do the work.
How to engage
We build the glue. PrivateLink and KMS architectures, IAM Identity Center wiring, audit-grade observability, change-data-capture pipelines into vector stores, the awkward bits where the agent has to talk to a 1998-vintage SOAP service. Talk to us at creativeminds.dev/contact, or fork the compliance-automator reference architecture which bakes most of the six surfaces above into a runnable system.