Three practical changes stand out: enforce authorization inside retrieval and tool loops for shared enterprise agents, route new-service creation through approved Backstage templates, and compile repeated program-synthesis work into reusable symbolic solvers. Each one gives the agent a bounded surface and a measurable check.

3 ideas

ABAC-gated retrieval and server-side tool execution for multitenant agents

Enterprise teams testing shared RAG agents should move authorization into the retrieval and tool loop. The concrete build is an ingestion path that tags every chunk with tenant and access metadata, a retrieval path that applies resource-level and chunk-level checks, and a server-side agent loop for tool execution, conversation state, audit logs, and policy checks.

The operational pain is clear: semantic search can return another tenant’s confidential data because relevance scoring has no built-in access check. In the OGX evaluation, ungated retrieval leaked cross-tenant data in 98–100% of cross-tenant probes. ABAC gating reduced Cross-Tenant Leakage Rate and Authorization Violation Rate to 0% in the reported setup across client-side and server-side orchestration modes.

A cheap adoption test is possible before any broad rollout. Seed a test corpus with three tenants, run authorized queries, cross-tenant probes, and prompt-injection probes, then measure leakage, authorization violations, and latency. The system should fail closed when metadata is missing or ambiguous.

Backstage template selection with a clarification chat for new service scaffolding

Platform engineering teams can reduce failed service starts by putting a retrieval layer over approved Backstage templates. The workflow is narrow: ask a few questions about service purpose, tech stack, database, API style, CI/CD needs, and security requirements; match the answers against the template catalog; generate the service start from the selected approved scaffold.

The value is in deployment fit. The service-scaffolding paper reports that open-ended coding assistance often misses company-specific CI/CD, Kubernetes, security, and platform rules. In its small evaluation, the template-selection system chose the ground-truth template in 10 of 10 runs. Only 2 of 7 Copilot users passed all deployment quality gates, while the template-selection system passed the gates with a median of 3 prompts and under 5 minutes of interaction.

The first internal test should use existing platform quality gates, not developer sentiment alone. Run the selector on recent service requests, compare the chosen templates with the platform team’s expected choices, and check whether generated projects pass CI/CD, security, deployment, and pod-log checks without manual repair.

Reusable symbolic solvers built from LLM reasoning traces for repeated program-synthesis tasks

Teams with many similar program-synthesis jobs can try an offline solver-building step. Collect successful and failed LLM reasoning traces for a task family, have a coding agent write a standalone Python solver over the allowed DSL or transformation language, then run the solver first and call an LLM only when the solver cannot satisfy the verifier.

ReaComp is the concrete case. It builds symbolic program synthesizers from about 100 reasoning traces per benchmark. On PBEBench-Hard, the symbolic ensemble reached 84.7% accuracy with no test-time LLM tokens, while Best-of-K reached 68.4%. The hybrid reached 85.8% accuracy and cut token use from 332.1M to 71.6M in the reported comparison.

The workflow fits domains where correctness can be checked by execution or a verifier, such as programming-by-example transformations, data-wrangling rules, and constrained code transformations. A practical pilot would pick one repeated task family, build the solver once, and track solved cases, verifier failures, fallback rate, and token spend against the current LLM-only path.