Credit: RAG
Enterprise software is approaching a shift where AI assistants generate features on demand rather than shipping them through product backlogs. Instead of filing a request and waiting months, a user describes what they need and the system generates a small program to do it. The article explores what this means for product teams, security, governance, and the definition of a ‘feature’ itself.
The enterprise feature backlog is where good user requests go to wait. That wait is about to get much shorter, not because product teams got faster, but because the missing feature can now be generated at request time and discarded thirty seconds later.
A support team lead opens her helpdesk application and asks:
“Show me every ticket this month that was resolved and then reopened within 48 hours, grouped by the agent who first closed it.”
No report does this. No filter combination can express it. No dashboard tile exists.
A few years ago, this would have become a ticket for the product team, logged, prioritized, and often delivered late or not at all. More recently, an AI assistant might have retrieved a knowledge article explaining how she could export ticket data and analyze it in a spreadsheet.
Now there is a third possibility. The assistant generates a small program for exactly this request. The program scans ticket records, cross-references each resolution event with subsequent reopenings, checks whether the gap was under 48 hours, and returns a grouped summary. The model receives that table and explains the pattern.
The product team never built the report. The user never wrote code. For one task, the missing feature existed exactly where it was needed.
That is not better retrieval. It is the beginning of programmable context.
Retrieval selects evidence. Code computes new evidence.
RAG solved a genuine problem: users could ask natural-language questions and get answers grounded in sources the interface never surfaced. But retrieval selects from evidence that already exists, a document, a passage, a row.
Many enterprise questions are not answered by any existing artifact. They are answered by a procedure: filtering, joining, calculating, and summarizing across sources.
Which tickets were reopened only after being transferred to a different team? Which expense reports exceed the department average by more than half? Which deployments failed this week that also failed last week, and what changed in between?
A product team can prebuild the common procedures. It cannot anticipate all of them.
That is the gap programmable context closes. The model translates a user’s intent into a temporary program. The application executes it against approved capabilities and places only the computed result into the context window. This is not a general-purpose code interpreter with access to the entire language, the application defines exactly which operations the generated code may call. The code may live for a single request, generated, executed, logged, discarded.
Users will decide what the AI actually sees
Every AI model has a limited working memory, the context window, that determines what it can reason about on each request. Managing that window has been invisible plumbing owned by platform teams. That remains critical. But a larger shift is becoming possible: users defining what enters context by describing the computation they need.
“Show me resolved tickets where the customer replied within a day, what are the common topics?” “Compare first-response time by agent this month versus last and flag anyone who got slower.” “Find expense reports submitted on the last day of the quarter, grouped by approver.”
Each request is a temporary feature. The generated program computes an answer-shaped artifact, and only that artifact enters context. This is context customization by intent, not by prompt tuning.
Where does the generated code actually run?
If a model can generate a reliable program, something still has to execute it. Server-side sandboxes are the obvious choice for heavy computation and cross-system joins. But there is a runtime most enterprise users already have open: the browser.
Every enterprise web application ships a JavaScript engine to every user who logs in. That engine can run generated code without a separate backend service, deployment step, or infrastructure request. The user does not install anything or switch tools, the computation happens inside the product they are already using.
Client-side execution also carries an important architectural advantage: the browser session already represents the signed-in user.
Suppose the helpdesk application gives generated JavaScript a narrow interface, listTickets, getTicketTimeline, getAgentStats. Each call travels to the backend using the current user’s delegated identity. The same role-based and record-level rules that govern the application’s screens govern the generated computation. No separate service account with broader access is needed.
That sidesteps a recurring agent architecture problem: a central identity that can see more than the person asking the question. The program retrieves only records the current user is entitled to see, processes them locally, and sends a compact result to the model, reducing both context usage and unnecessary data movement.
Client-side execution becomes a context-engineering strategy: compute near the user, under the user’s identity, and give the model answer-shaped evidence rather than raw records.
Identity is necessary but not sufficient
There is a dangerous version of this idea: generate JavaScript and run it with eval() inside the main application page, giving it full access to the DOM, browser storage, write endpoints, and outbound network.
A safer path exists in the language. The new Function() constructor compiles a string into a function that cannot capture the calling scope’s local variables, but it still runs in global scope unless further contained. Combined with a sandboxed iframe or worker, it becomes a practical execution boundary where the application hands the generated function only the capabilities it chooses.
Running on the client does not make authorization automatic. The browser supplies identity; the server must still authorize every API request.
A credible design gives generated code capabilities, not credentials. It runs in an isolated worker, sandboxed frame, or constrained runtime, no unrestricted access to the document, cookies, network, or filesystem. The application exposes a small set of typed, auditable operations. Reads are default. Writes require a separate grant and, for consequential actions, explicit confirmation.
The runtime needs limits on execution time, memory, result size, and API call count. Every run should log the generated program, the requesting identity, capabilities invoked, and data provenance.
One more boundary matters and is easy to miss: permission to view a record does not imply permission to send it to any model endpoint. Before a computed result enters the context window, the application must apply its data-handling and model-eligibility policies.
The principle is simple: let generated code compute. Never let it escape.
From feature catalogs to computation environments
Client-side JavaScript and server-side skills are two instances of the same emerging pattern.
A reusable skill might contain a reviewed Python script for a recurring task. An ephemeral program might be generated for one question and never run again. A browser runtime suits interactive analysis under delegated identity. A server sandbox handles expensive computation and cross-system access.
Product teams still ship features, and repeated computations should graduate into permanent ones. But builders also create the governed execution surface from which unanticipated features can be assembled: safe capabilities, identity propagation, policy enforcement, sandboxes, and provenance.
Users do not gain unconstrained access, and they do not become software engineers. They gain something more practical: the ability to request computations the product team did not know to build, inside boundaries that team deliberately designed.
This is not yet standard practice, but every component is production-ready. RAG let users ask questions the interface did not anticipate. Programmable context lets systems compute answers the feature roadmap did not anticipate.
The support lead who wanted to know which agents keep closing tickets prematurely? She has her answer, not because someone shipped a report, but because the application let her describe what she needed and computed it on the spot. The question worth asking your own team: could your product do the same?
Get the most important tech news in your inbox each week.
Contributed article. Not produced by the TNW newsroom and does not reflect the editorial stance of TNW.
