Decoding Ontology for Modern Software Architecture

Architectural Primitives for Non-Deterministic Software — Agentic AI, AI Agents, Multi-Agent Orchestration, LLMs, and Explainable AI

0. The Paradigm Shift

Software engineering built its last fifty years on determinism: same input, same output, every time. Agentic AI breaks that contract. The core reasoning unit — an LLM — is probabilistic. Two things stop that probabilism from becoming chaos in production, and everything else in this piece is built to support them:

1. A routing layer that picks the cheapest model/path capable of a correct answer, rather than sending every request to the biggest model available.
2. A self-correcting validation layer that enforces type safety and schema conformance on everything the model produces, before it reaches a downstream system.

Treating the LLM as a single magical black box — one giant prompt trying to do planning, retrieval, formatting, and validation at once — is the reliable way to get a brittle, unscalable system. High-performing 2026 architectures decouple these concerns instead. Underneath both primitives sits a third thing that rarely gets named but does the actual semantic work: an ontology — the formal, machine-checkable model of what a “patient,” a “claim,” or a “lab observation” actually is — which is what a routing decision and a validation check both ultimately measure themselves against. That’s the throughline of this piece: ontology isn’t a side discipline next to agentic engineering, it’s the substrate the other disciplines are built on top of.

1. The Routing Layer: Picking the Cheapest Correct Path

By 2026, no serious production system sends every request to one frontier model. A routing (or “model broker”) layer evaluates each request’s complexity and picks the cheapest model that clears a quality bar for that task type — Azure AI Foundry’s Model Router, for instance, runs a trained classifier in front of 27+ models with explicit Balanced / Cost / Quality modes [1]. The architectural insight isn’t “use cheap models” — it’s that intelligence increasingly lives in the router, not in any single model, because the model ecosystem has stratified into cheap extraction-tuned models, mid-tier reasoning specialists, and frontier models for genuinely novel problems [2].

Healthcare use case. A Clinical AI Data Platform fields thousands of queries per shift: “what’s the reference range for potassium” needs a sub-second, near-zero-cost lookup; “reconcile this patient’s five-drug regimen against their new diagnosis for contraindications” needs a frontier reasoning model with tool access to an interaction database. Routing these identically — either all to the frontier model (unaffordable at ICU scale) or all to a cheap model (unsafe for the second case) — is the naive failure mode the routing layer exists to prevent. The routing decision itself should be ontology-aware: a query touching a ContraindicationCheck concept routes differently than one touching a ReferenceRangeLookup concept, because the ontology is what tells the router which category a request falls into.

2. The Validation Layer: Self-Correcting Type Safety

The second primitive assumes the model will occasionally produce malformed, incomplete, or subtly wrong output — and catches it before it reaches anything downstream. The dominant 2026 pattern: define a strict schema (a Pydantic model or JSON Schema), force the model’s output through it, and on failure, feed the validation error back to the model as context and retry rather than failing silently or crashing [3][4]. Pydantic AI’s validation-retry mechanism is the reference implementation: a ValidationError becomes the next prompt’s context, and most models self-correct within one or two retries [5]. Gateway-level validators add a second checkpoint at the infrastructure boundary — structural correctness, schema correctness, then content correctness — so a single SDK-level check isn’t the only line of defense [6].

Healthcare use case. An agent drafting a structured MedicationRequest FHIR resource must never let a malformed dosage field (“500” with no unit, or a unit mismatched to the drug class) reach the EHR write API. A Pydantic schema with explicit dosage, unit (enum-constrained), and frequency fields catches this before the write call executes; on failure, the model receives “your previous output had dosage unit ‘mL’ for a tablet-form medication — regenerate” and corrects on retry. This is a categorically different guarantee than “the output looked plausible.”

3. Ontological Engineering: The Semantic Substrate Underneath Both Primitives

An ontology is what lets the routing layer know a request is a ContraindicationCheck and lets the validation layer know a MedicationRequest.dosage field has a bounded, typed range. Ontological engineering is the applied discipline of building that substrate — not a diagram exercise, but a lifecycle: specification (competency questions), conceptualization, formalization (RDF/OWL/SHACL), implementation, evaluation, and maintenance.

3a. Patterns Worth Copying

• Reuse before reinvention. Anchor to SNOMED CT, LOINC, RxNorm, and HL7 FHIR for clinical concepts rather than deriving a custom taxonomy — a mature “ontology-first” architecture treats standardized schemas as the default, not an option [7].
• Human-led boundary-setting, LLM-accelerated extraction. LLMs cannot generate a trustworthy core ontology unsupervised — domain subject-matter experts must define the boundaries; the LLM’s role is accelerating extraction and drafting inside those boundaries [7][8].
• Ontology-to-tool compilation. A single ontology, compiled once, should generate the SHACL constraint, the JSON tool schema, and the API contract — one source of truth enforced identically everywhere, an approach formalized in recent work on executable semantic constraint enforcement for LLM agents [9].
• Ontology matching over ontology reinvention. When two systems (a vendor EHR schema and an internal one) model the same concept differently, LLM-agent-based ontology matching frameworks now automate much of the alignment that used to be manual mapping-table work [10].

3b. Anti-Patterns That Reliably Break Production Systems

A 2026 Knowledge Graph Conference review identified five recurring ontology anti-patterns: hierarchy explosion (a taxonomy that grows subclasses faster than the domain justifies), inconsistent taxonomy (the same concept modeled two different ways in two parts of the graph), property growth (attributes bolted onto a class ad hoc instead of modeled properly), concept–instance confusion (treating a specific patient record as if it were a class), and modelling by association (linking things because they co-occur in data, not because a real relationship exists) [11].

A subtler failure specific to enterprises: ontologies work well for domains where meaning changes slowly — “myocardial infarction” means the same thing in 2026 as it did twenty years ago — but an enterprise’s own operational concepts (what counts as an “active patient,” a “closed encounter”) can shift multiple times a year, and a static ontology with no drift-detection mechanism quietly goes stale [12]. Practically, semantic governance at scale requires a real staffing commitment — production deployments report needing roughly one dedicated steward per 50–100 entity types on an ongoing basis, not as a one-time build cost [13].

Healthcare use case. If Cardiology defines “active patient” as “has an appointment in the next 90 days” while Billing defines it as “has an open encounter,” a care-gap alert agent querying “active patients overdue for an A1c test” will silently undercount or overcount depending on which definition its underlying data model happens to inherit — a textbook inconsistent-taxonomy failure that a single canonical Patient.status concept, governed once, eliminates.

4. Prompt Engineering: English as the New Programming Language

Andrej Karpathy’s framing — that English became “the hottest new programming language” for interacting with LLMs [14] — is the correct starting point but not the ending point. Prompt engineering optimizes a single interaction: phrasing, examples, format constraints. It’s necessary — a clinician’s natural-language chart-review instruction has to compile down into something the routing layer, the validation schema, and the ontology can all act on — but it doesn’t survive contact with multi-turn, multi-session, multi-agent systems. That gap is exactly why the disciplines below emerged: loop engineering optimizes the behavior around a prompt, harness engineering optimizes the system around the model, and context engineering optimizes what the model sees over time. Each is a response to prompt engineering’s ceiling, not a replacement for it.

5. Loop Engineering: Designing the Reason-Act-Observe Cadence

By mid-2026, the field’s center of gravity moved from “prompt the agent” to “design the loop that prompts the agent for you” — a shift widely credited to Addy Osmani’s June 2026 essay, building on comments from Peter Steinberger and Anthropic’s Boris Cherny [15]. The foundational pattern underneath every loop is ReAct — alternating reason and act, using each observation to inform the next step [16] — with Reflexion adding verbal self-critique between attempts [17]. Geoffrey Huntley’s “Ralph” technique, popularized earlier in 2026, demonstrated a strikingly simple variant: run the same prompt against a written spec in a plain while-loop, resetting context between iterations rather than letting a single session degrade [18].

Four loop shapes cover most production systems [19][20]:

Healthcare use case. A sepsis-screening agent runs on a heartbeat — waking every 15 minutes to check newly posted vitals and labs against SIRS/qSOFA criteria. If nothing crosses threshold, it sleeps; if a patient’s lactate and heart-rate trend cross a defined boundary, it escalates to a care-coordination agent. The failure modes to guard against are well documented: prompt injection through the very data the loop observes (a free-text nursing note is untrusted input, same as a web page), and context degradation across long-running sessions, both of which argue for periodic context resets and sandboxed execution [20].

6. Harness Engineering: The Control Plane Around the Model

If loop engineering designs the cadence, harness engineering designs everything around the model that makes that cadence safe and repeatable. The formula that’s become shorthand for the discipline: Agent = Model + Harness — the model is treated as a frozen reasoning utility, and the responsibility for safety, execution accuracy, and adaptive memory is stripped out of the model and handed to the surrounding infrastructure [21][22]. Mitchell Hashimoto’s operating premise for the discipline: whenever an agent makes a mistake, the fix isn’t a better prompt — it’s engineering the harness so that specific mistake becomes structurally impossible to repeat [22].

A production harness typically has five layers: tool orchestration, verification loops, context/memory, guardrails, and observability [22]. A useful architectural distinction is inner harness vs. outer harness — frontier labs build the inner harness (native tool-calling, safety layers baked into the model API); the enterprise’s own engineering moat is the outer harness — custom routing, environment-specific guardrails, and situational policy layered on top [23]. This is also where “Agent = Model + Harness” gets measured, not just claimed: one team reported moving a coding agent from 30th to 5th place on a standard benchmark purely by improving the harness, without touching the underlying model [24].

Healthcare use case. The outer harness around a clinical documentation agent is where HIPAA de-identification runs before any PHI reaches an external tool call, where every action gets an immutable audit-log entry, and where a human-approval gate blocks any agent action tagged high-risk (e.g., anything that writes to the medication record) until a clinician confirms it. None of that lives in the model — it lives in the harness, which is exactly the point.

7. Fleet Engineering: Orchestrating Multi-Agent Systems at Scale

Multi-agent orchestration went from a niche pattern to the default enterprise architecture extraordinarily fast — Gartner logged a 1,445% increase in multi-agent-system inquiries between Q1 2024 and Q2 2025, with 40% of enterprise applications projected to include AI agents by the end of 2026 [25]. Fleet engineering is the operational discipline of running that fleet as one coherent system rather than a pile of independently-built agents: shared workspace locking to prevent race conditions when multiple agents touch the same record, a shared semantic index so agents aren’t each maintaining their own local knowledge, and defined operational pillars — deploy, configure, monitor, update, scale, retire — applied consistently across the fleet [26].

Architecturally, orchestration splits into centralized (a supervisor agent decomposes and delegates) and decentralized/choreographed (agents coordinate peer-to-peer via a shared protocol, without a central controller) [27][28]. Selective, cost-aware delegation — routing a subtask to a smaller specialist agent rather than a large general one — is itself an active research area, directly extending the Section 1 routing-layer idea from single-model selection to whole-agent selection [29].

Healthcare use case. This maps directly onto a Supervisor–Critic fleet spanning clinical departments — a radiology agent, a pharmacy agent, a care-coordination agent, each specialized and independently scoped, coordinated by a supervisor that decomposes a case (e.g., “new oncology admission”) into department-specific subtasks, with a critic agent validating each department’s output against the shared ontology before it’s committed to the patient record.

8. Agent Skills: Composable, Portable Capability Units

Anthropic’s October 2025 introduction of Agent Skills [30], followed by an open specification published in December 2025 [31], formalized a pattern that had been emerging informally: package a capability — instructions, reference material, and optionally scripts — as a discrete, portable unit an agent can invoke rather than re-deriving from a monolithic system prompt every time. Recent surveys frame this as a distinct research area from tool-use generally, covering skill acquisition, retrieval at scale (skill libraries now routinely exceed what fits in a single context window, motivating graph- and cluster-based retrieval methods), and security — an unvetted third-party skill is executable content, with the same trust boundary as any other untrusted input [32][33].

Healthcare use case. A “prior-authorization drafting” skill — encoding payer-specific formatting rules, required clinical justification fields, and CPT/ICD-10 code lookups — gets built once and invoked identically by the oncology, cardiology, and orthopedics department agents, rather than three teams independently (and inconsistently) reimplementing the same logic.

9. Agent Memory: Persistent State Across Sessions

An agent that “forgets everything” between sessions is the single most-cited production complaint driving 2026 investment in memory architecture [34]. The research distinguishes knowledge memory (facts, entities, relationships — often graph-structured) from experience memory (what worked, what didn’t, in past task attempts) [35][36]. HippoRAG’s neurobiologically-inspired approach to long-term memory demonstrated that graph-structured memory retrieval can approach human-like long-term recall performance for LLM agents [37], and lightweight memory-augmentation approaches are converging on the same graph-first intuition to keep the technique affordable at scale [38]. A related, easily overlooked constraint: simply having a longer context window doesn’t solve memory — models reliably attend less to information buried in the middle of a long context, the well-established “lost in the middle” effect, which is an argument for structured retrieval over just stuffing everything into the window [39].

Healthcare use case. A diabetes-management agent shouldn’t re-derive a patient’s insulin-titration history from scratch at every visit. Persistent, graph-structured memory — this patient’s dose-response pattern, prior adverse reactions, care-plan adjustments — lets the agent pick up longitudinally, the same way a continuity-of-care physician would, rather than treating every encounter as a cold start.

10. Agentic Context Engineering: Building Self-Improving Systems

ACE (Agentic Context Engineering) is the most rigorously benchmarked answer to a specific problem: prior approaches to adapting an agent’s context over time suffered from brevity bias (iterative summarization quietly drops domain detail) and context collapse (repeated rewriting erodes what made earlier successes work) [40]. ACE instead treats context as an evolving playbook, maintained through three roles — a Generator that produces reasoning trajectories, a Reflector that critiques what worked and what didn’t, and a Curator that makes small, targeted deltas to the playbook rather than rewriting it wholesale [41]. Reported gains: +10.6% on agent benchmarks and +8.6% on finance benchmarks over strong baselines, achieved through context evolution alone — no weight updates [40]. Critically, ACE adapts from natural execution feedback, not labeled supervision, which is what makes it viable as an ongoing production process rather than a one-time fine-tuning project.

A useful caution from the same body of research: auto-generated context files can reduce task success versus a minimal, human-curated file, and both increase inference cost meaningfully — bigger isn’t better; curated and small beats large and automatically assembled [42].

Healthcare use case. A clinical documentation agent’s playbook accumulates successful phrasing patterns and structuring choices specifically from clinician edits over months — if clinicians in a given department consistently restructure a specific section of the agent’s discharge-summary draft, the Curator role folds that correction into the playbook as a standing strategy, without anyone retraining the underlying model.

11. Feature Engineering, Reframed: From Raw Data to Semantic Predictive Power

Classical feature engineering — transforming raw fields into the derived signals a model can actually learn from — hasn’t disappeared under LLMs; it’s been extended. Recent work reframes the classical feature-engineering discipline (refactor the representation, break down complex signals, compile them into interpretable outputs) as a cognitive-architecture pattern specifically for LLM-based monitoring agents, explicitly borrowing the “refactor / break down / compile” sequence from traditional feature engineering to make agent planning more deterministic and less dependent on unconstrained LLM-generated reasoning [43]. Separately, LLMs are now used to generate semantic features directly from unstructured text and logs — sentiment, topic, risk category — that traditional numeric feature engineering could never extract from the same raw source [44].

The place this connects back to Section 3: a “feature” in this reframed sense is most useful when it’s mapped to an ontology concept, not just a numeric column — the same discipline that resolves “glucose,” “GLU,” and a LOINC code to one canonical concept for a clinical agent is doing feature engineering and ontological grounding simultaneously.

Healthcare use case. Raw continuous glucose monitor telemetry — a stream of readings every five minutes — isn’t directly useful to either a classical risk model or an LLM agent. Feature engineering transforms it into ontology-mapped clinical concepts like TimeInRange, GlycemicVariabilityIndex, and NocturnalHypoglycemiaFlag — features a classical ML model can score and an LLM agent can reason over using the same shared vocabulary.

12. Explainable AI (xAI): The Cross-Cutting Requirement

Explainability in a multi-agent system is a fundamentally different problem than explaining a single model’s prediction — outcomes emerge from interactions among specialized agents, so explaining a decision means tracing which agent performed which sub-task, what data it used, and how inter-agent exchanges shaped the final outcome [45]. Trust, Risk, and Security Management (TRiSM) frameworks for agentic AI formalize this as a dedicated architectural layer — a Trust & Explainability plane sitting alongside ModelOps, planning/reasoning, and privacy, cross-cut by a monitoring and governance layer that every other layer reports into [46]. A growing body of work calls this the “transparency gap”: agentic AI capability has scaled far faster than the explainability methods designed to keep pace with it, since most XAI tooling was built for static, single-model predictions [47]. One promising direction closing that gap: agentic XAI, where an LLM agent iteratively refines a technical explanation (e.g., a SHAP output) into a progressively clearer natural-language narrative for a non-technical audience, rather than dumping a static explanation once [48].

Healthcare use case. When a sepsis-risk escalation reaches a clinical governance committee for review, the audit trail needs to answer: which agent triggered it, which specific lab values and ontology concepts it reasoned over, which department’s data contributed, and what the routing layer’s confidence threshold was at the moment it escalated rather than suppressed. That’s not a “nice to have” — it’s the artifact a hospital’s compliance and quality-assurance function will actually ask for.

13. Forward Deployed Engineering: Shifting Left to Prove Business Impact

An MIT NANDA study examining 300 enterprise generative-AI pilots found that roughly 95% produced no measurable profit-and-loss impact — and traced the failure to integration, not model quality: systems that couldn’t talk to legacy databases, couldn’t handle the customer’s authentication stack, or couldn’t meet data-residency requirements [49]. Forward Deployed Engineering — a role and operating model Palantir originated in 2008 under the internal name “Deltas” [50] — is the industry’s answer: embed senior engineers directly inside the customer’s environment, under real governance and real data constraints, shipping production integrations rather than handing over a roadmap. By 2026 the model went mainstream at the frontier-lab level: both Anthropic and OpenAI launched dedicated enterprise-services ventures built around embedded engineering in the same year, and AWS followed with its own billion-dollar Forward Deployed Engineering unit [51][52][53].

The architectural point, not just the org-design point: FDE is what “shift left” means in practice for agentic AI — instead of building a generalized platform in isolation and hoping it transfers, the routing thresholds, the harness’s guardrail specifics, and the ontology’s initial scope all get discovered and hardened inside the first real deployment, then generalized outward.

Healthcare use case. Embedding an engineer inside the hospital’s clinical informatics team — working against the actual Epic/Cerner instance, the actual HL7 interface engine, the actual identity-and-access constraints — is what closes the gap between a Clinical AI Data Platform’s demo and a production deployment that survives contact with a real EHR, real clinician workflows, and a real compliance review.

14. Synthesis: How the Primitives Compose in a Healthcare Clinical AI Platform

Pulled together, these aren’t fifteen separate disciplines — they’re layers of one architecture:

Ontology (SNOMED CT / LOINC / RxNorm / FHIR)  ─── the semantic contract everything below checks against
        │
        ▼
Routing Layer ── picks cheapest correct model/agent per request, ontology-aware
        │
        ▼
Harness (guardrails, HIPAA de-id, audit log, human-approval gates)
        │
        ▼
Loop (heartbeat / cron / hook / goal-directed reason-act-observe cycle)
        │
        ▼
Fleet (Supervisor-Critic orchestration across department agents)
        │
        ▼
Agent Skills (reusable capability units) + Agent Memory (longitudinal patient context)
        │
        ▼
Agentic Context Engineering (playbook improves from clinician feedback over time)
        │
        ▼
Validation Layer ── schema-checked, type-safe output before any EHR write
        │
        ▼
Explainable AI ── full trace, for every layer above, on demand

Forward Deployed Engineering is how this stack gets proven against one department’s real data before it’s generalized across all ten. Feature engineering is what turns the raw device telemetry and EHR fields at the very bottom of the stack into something the ontology can even attach meaning to in the first place. Prompt engineering is the substrate language every layer above ultimately compiles down to when a human — a clinician, an architect — needs to instruct any part of the system directly.

None of this works if the ontology at the top is wrong, undermaintained, or privately reinvented by one department — which is the entire argument for treating ontological engineering as infrastructure, not documentation.

References

1. LLM Model Routing in 2026: Cost-Quality Optimization. Azure AI Foundry Model Router coverage. https://www.digitalapplied.com/blog/llm-model-routing-2026-cost-quality-optimization-engineering-guide
2. Beyond the Monolith: How Multi-Model Routing Is Redefining LLM Orchestration in 2026. Mindra Blog. https://mindra.co/blog/multi-model-routing-llm-orchestration-2026
3. LLM Guardrails and Safety in Production AI Systems. Medium, April 2026.
4. What is LLM Input/Output Validation? The 2026 Explainer. FutureAGI. https://futureagi.com/blog/what-is-llm-input-output-validation-2026/
5. Pydantic AI Tutorial 2026: Type-Safe Python Agents With Automatic Validation and Self-Correction. RockB. https://baeseokjae.github.io/posts/pydantic-ai-tutorial-2026/
6. What is LLM Input/Output Validation? The 2026 Explainer. FutureAGI (gateway-level validation layer). https://futureagi.com/blog/what-is-llm-input-output-validation-2026/
7. Ontology-First AI Architecture: Definition, Components, Examples, and 30-Day Plan. Atlan, 2026. https://atlan.com/know/ontology-first-ai-architecture/
8. Build an Enterprise Ontology Your LLM Can Use. Sanjay Saini, June 2026.
9. Zhou, X., Butler, P., Yang, C., Rihm, S., Angkanaporn, T., Akroyd, J., Mosbach, S., & Kraft, M. (2026). Ontology-to-tools compilation for executable semantic constraint enforcement in LLM agents. arXiv:2602.03439.
10. Agent-OM: Leveraging LLM Agents for Ontology Matching. Proceedings of the VLDB Endowment / arXiv:2312.00326.
11. Knowledge Graph Conference 2026 — five ontology anti-patterns. Graph Research Labs. https://graphresearchlabs.com/kgc2026-links/
12. How Enterprise Ontologies Decay — And How to Stop It. Alation, April 2026. https://www.alation.com/blog/living-ontologies-enterprise-ai/
13. Enterprise Knowledge Graph Buyer’s Guide 2026. Promethium. https://promethium.ai/guides/enterprise-knowledge-graph-buyers-guide-2026/
14. Karpathy, A. — “English is the hottest new programming language” (widely cited framing of prompt engineering).
15. What Is Loop Engineering? A Complete Guide from Prompt to Harness Engineering (2026). Tosea.ai, citing Addy Osmani (June 2026). https://tosea.ai/blog/loop-engineering-ai-agents-complete-guide-2026
16. Yao, S. et al. (2022). ReAct: Synergizing Reasoning and Acting in Language Models.
17. Shinn, N. et al. (2023). Reflexion: Language Agents with Verbal Reinforcement Learning.
18. Loop Engineering: The Guide for AI Agents. Lushbinary, on Geoffrey Huntley’s “Ralph” technique. https://lushbinary.com/blog/loop-engineering-ai-coding-agents-guide/
19. Loop Engineering (2026): Self-Prompting AI Agent Patterns. Agent Shortlist. https://agentshortlist.com/articles/loop-engineering
20. Loop Engineering for AI Agents (2026 Guide). HappyCapy Blog. https://happycapy.ai/blog/loop-engineering-ai-agents
21. Harness Engineering for AI Agents in 2026. Vishal Mysore, Medium, May 2026.
22. Harness Engineering: Making AI Coding Agents Work in 2026. Faros.ai, citing Mitchell Hashimoto. https://www.faros.ai/blog/harness-engineering
23. Harness Engineering for AI Agents in 2026 — Inner Harness vs. Outer Harness distinction. Vishal Mysore, Medium.
24. Harness Engineering: Making AI Coding Agents Work in 2026. Faros.ai (LangChain Terminal Bench 2.0 example).
25. Gartner (2025), cited in Invisible Orchestrators Suppress Protective Behavior and Dissociate Power-Holders: Safety Risks in Multi-Agent LLM Systems. arXiv:2605.13851.
26. AI Agent Fleet Management: Complete Scaling Guide for 2026. Fastio. https://fast.io/resources/ai-agent-fleet-management/
27. What is AI Agent Orchestration? IBM. https://www.ibm.com/think/topics/ai-agent-orchestration
28. Adimulam, A., Gupta, R., & Kumar, S. (2026). The orchestration of multi-agent systems: Architectures, protocols, and enterprise adoption. arXiv:2601.13671.
29. Uno-Orchestra: Parsimonious Agent Routing via Selective Delegation. arXiv:2605.05007.
30. Zhang, B., Lazuka, K., & Murag, M. (2025). Equipping agents for the real world with agent skills. Anthropic Engineering Blog.
31. Agent Skills open standard specification, December 2025. https://agentskills.io
32. Xu, R., & Yan, Y. (2026). Agent skills for large language models: Architecture, acquisition, security, and the path forward. arXiv:2602.12430.
33. A Comprehensive Survey on Agent Skills: Taxonomy, Techniques, and Applications. arXiv:2605.07358.
34. Context Engineering: Why Agent Memory Is the Real AI Skill of 2026. Nicolas Meridjen Blog. https://blog.nicolasmeridjen.com/en/blog/2026-04-13-context-engineering-agent-memory-changes-everything/
35. Du, P. (2026). Memory for autonomous LLM agents: Mechanisms, evaluation, and emerging frontiers. arXiv:2603.07670.
36. Huang, W. et al. (2026). Rethinking memory mechanisms of foundation agents in the second half: A survey. arXiv:2602.06052.
37. Gutierrez, B. J. et al. HippoRAG: Neurobiologically inspired long-term memory for large language models. ICML 2025.
38. Fang, J. et al. (2025). LightMem: Lightweight and efficient memory-augmented generation. arXiv:2510.18866.
39. Liu, N. F. et al. (2024). Lost in the Middle: How Language Models Use Long Contexts. Transactions of the Association for Computational Linguistics, 12.
40. Zhang, Q., Hu, C., Upasani, S., et al. (2025/2026). Agentic Context Engineering: Evolving Contexts for Self-Improving Language Models. arXiv:2510.04618 (ICLR 2026).
41. Agentic Context Engineering: the complete guide to understanding the future of self-improving AI Systems. Léa La Roze, Medium, January 2026.
42. Gloaguen, T. et al. (2026). Evaluating AGENTS.md. arXiv:2602.11988.
43. Bravo-Rocca, G., Liu, P., Guitart, J., Carrillo-Larco, R. M., Dholakia, A., & Ellison, D. (2025). Feature Engineering for Agents: An Adaptive Cognitive Architecture for Interpretable ML Monitoring. AAMAS 2025.
44. Feature Engineering with LLMs: Techniques & Python Examples. Analytics Vidhya, May 2026. https://www.analyticsvidhya.com/blog/2026/05/feature-engineering-with-llms/
45. TRiSM for Agentic AI: A Review of Trust, Risk, and Security Management in LLM-based Agentic Multi-Agent Systems. ScienceDirect / arXiv:2506.04133.
46. TRiSM for Agentic AI — TRISM-Aligned Architecture, four-layer model. arXiv:2506.04133.
47. VectorInstitute. Agentic-Transparency: Bringing transparency to agentic AI across the full run. GitHub, 2026.
48. Yamaguchi, T., Zhou, Y., Ryo, M., & Katsura, K. (2025/2026). Agentic Explainable Artificial Intelligence (Agentic XAI) Approach To Explore Better Explanation. arXiv:2512.21066.
49. MIT NANDA (2025) study of 300 enterprise generative-AI pilots, cited in Why Forward Deployed Engineers Are the Hottest Job in 2026. Christian & Timbers. https://www.christianandtimbers.com/insights/why-forward-deployed-engineers-are-the-hottest-job-in-2026
50. AI Giants Bet Billions On The Most Expensive Job In Enterprise. Forbes, May 2026 (Palantir FDE origin, “Deltas”).
51. AWS launches $1 billion Forward Deployed Engineering unit to accelerate enterprise AI adoption. MarketScale, July 2026.
52. Introducing Forward Deployed Engineering for Partners. AWS Partner Network Blog, 2026. https://aws.amazon.com/blogs/apn/introducing-forward-deployed-engineering-for-partners-winning-the-future-of-enterprise-ai/
53. AI Giants Bet Billions On The Most Expensive Job In Enterprise. Forbes (Anthropic/OpenAI enterprise-services ventures, 2026).