Agent skill
cva-concepts-agent-types
Agent system taxonomy (A/B/C/D) based on capabilities - Type A (pure AI), Type B (AI+database context), Type C (AI+web grounding), Type D (AI+database+web). Includes latency/cost analysis, decision tree, healthcare pipeline mapping, and ROI optimization. Use when designing agent architecture, selecting agent type, optimizing costs, or implementing multi-agent workflows.
Install this agent skill to your Project
npx add-skill https://github.com/majiayu000/claude-skill-registry/tree/main/skills/data/cva-concepts-agent-types
SKILL.md
Agent System Types (A/B/C/D Taxonomy)
Core Concept: Taxonomy of AI agent systems based on their capabilities (data sources) Origin: Validated architecture from FluSisTip project (healthcare production system) Applicability: Generic for any regulated domain or rich-context requirements
🎯 Overview
In production AI agent development, especially in regulated domains (healthcare, legal, finance), not all agents need the same capabilities. The A/B/C/D typology classifies agents by type of data they access, enabling cost, performance, and complexity optimization.
Complexity Hierarchy
Type A (Pure AI)
↓ +Database Context
Type B (AI + CAG)
↓ +Web Grounding
Type C (AI + Web)
↓ +Database Context
Type D (AI + CAG + Web)
📊 Quick Comparison
| Type | Capabilities | Cost | Latency | Use Cases | Vertex AI Feature |
|---|---|---|---|---|---|
| A | Pure AI | $ | ~3s | Analysis, classification, extraction | Standard prompting |
| B | AI + CAG | $$ | ~5s | Personalization, compliance | Context injection |
| C | AI + Web | $$$ | ~12s | Research, external validation | Grounding API |
| D | AI + CAG + Web | $$$$ | ~17s | Maximum context consolidation | Context + Grounding |
Cost Legend:
- $ = $0.001 - $0.05
- $$ = $0.05 - $0.15
- $$$ = $0.15 - $0.30
- $$$$ = $0.30 - $0.50
🔷 Type A: Pure AI
Definition
Direct input → LLM → Structured output
Agent processes only data provided in input (by user or previous system in workflow). No database access, external APIs, or web search.
Characteristics
- ✅ Fastest: ~3s average time
- ✅ Cheapest: ~$0.02 per execution
- ✅ Deterministic: Same input = same output
- ✅ Stateless: No state between calls
- ❌ Limited context: Only what's in the prompt
When to Use
- Analysis & Extraction: Identify entities, extract structured data
- Classification: Categorize content, detect sentiment
- Transformation: Convert formats, restructure data
- Syntactic Validation: Check format, data completeness
- Query Generation: Create search strategies
Healthcare Example: S.1.2 - Claims Identification
Function: Identify medical claims in raw text requiring scientific validation
Implementation Pattern (Clojure):
(ns lab.agents.claims-identifier
"Type A: Pure AI - Medical claims identification"
(:require [lab.config.google-cloud :as gc])
(:import [com.google.cloud.vertexai VertexAI]
[com.google.cloud.vertexai.generativeai GenerativeModel]))
(defn create-claims-agent
"Creates Type A agent for medical claims identification."
[{:keys [project-id location model]
:or {model "gemini-1.5-flash"}}]
(let [vertex-ai (VertexAI. project-id location)
generation-config (-> (GenerationConfig/newBuilder)
(.setTemperature 0.2) ; Low for technical analysis
(.setMaxOutputTokens 2000)
(.build))
model-instance (.getGenerativeModel vertex-ai model)]
(.withGenerationConfig model-instance generation-config)))
(defn identify-claims
"Identifies medical claims in content."
[agent content specialty]
(let [prompt (format
"Analyze this %s content and extract ALL scientific claims
that require validation. Return JSON with 'claims' array."
specialty content)
response (.generateContent agent prompt)
text (-> response .getText)]
(cheshire.core/parse-string text true)))
Real Metrics (Healthcare Pipeline):
- Average time: 3.2s
- Average cost: $0.018
- Success rate: 96.1%
- Average tokens: 520 total
🔶 Type B: AI + CAG (Context-Aware Generation)
Definition
Input + Database Context → LLM → Personalized output
Agent enriches prompt with data from tenant database (Context-Aware Generation). Enables personalization based on history, profile, stored business rules.
Characteristics
- ✅ Rich context: Access tenant data (regulations, profiles, history)
- ✅ Personalized: Adapts output to specific context
- ✅ Compliance: Incorporates stored business rules
- ⚠️ Query overhead: +2s to fetch contexts
- ⚠️ Cache important: Contexts should be cached (TTL 1h+)
When to Use
- Output Personalization: Adapt tone, style, language to profile
- Dynamic Compliance: Apply tenant-specific rules
- History: Consider previous interactions/decisions
- Custom Configuration: Client-specific guidelines
- Rule Validation: Check conformance with stored policies
Healthcare Example: S.3-2 - SEO + Professional Profile
Function: Optimize content for SEO considering professional profile and specialized keywords
Implementation Pattern (Clojure):
(ns lab.agents.seo-optimizer
"Type B: AI + CAG - SEO optimization with tenant context"
(:require [lab.config.google-cloud :as gc]
[next.jdbc :as jdbc]))
(defn fetch-professional-profile
"Fetches complete professional profile (Context 1)."
[db-spec prof-id]
(jdbc/execute-one!
(jdbc/get-datasource db-spec)
["SELECT nome_completo, crm, especialidade, anos_experiencia,
tom_voz, cidade_atuacao
FROM profissionais
WHERE id = ?::uuid"
(str prof-id)]
{:builder-fn rs/as-unqualified-lower-maps}))
(defn fetch-seo-keywords
"Fetches specialized SEO keywords (Context 2)."
[db-spec specialty city]
(jdbc/execute!
(jdbc/get-datasource db-spec)
["SELECT keyword, tipo, search_volume
FROM seo_keywords
WHERE especialidade = ? AND cidade = ?
ORDER BY relevancia DESC LIMIT 10"
specialty city]
{:builder-fn rs/as-unqualified-lower-maps}))
(defn optimize-seo
"Optimizes content for SEO with professional context."
[agent db-spec content prof-id]
(let [profile (fetch-professional-profile db-spec prof-id)
keywords (fetch-seo-keywords db-spec
(:especialidade profile)
(:cidade_atuacao profile))
prompt (build-enriched-prompt content profile keywords)
response (.generateContent agent prompt)]
(parse-response response)))
Real Metrics:
- Average time: 5.2s (3.1s LLM + 2.1s queries)
- Average cost: $0.078
- Success rate: 94.7%
- Cache critical: Reduces queries by 85% with 1h TTL
🔷 Type C: AI + Web (Grounding)
Definition
Input + Web Search/Grounding → LLM → Validated output
Agent performs real-time external searches (web, scientific databases, public APIs) to enrich context and validate information. Uses Vertex AI Grounding API or custom tools.
Characteristics
- ✅ External updated data: Doesn't depend on model knowledge
- ✅ Real-time validation: Search evidence, prices, availability
- ✅ Trusted sources: PubMed, Google Scholar, specialized APIs
- ⚠️ High latency: +8-12s for complete grounding
- ⚠️ High cost: $0.15-0.30 per execution
- ⚠️ Rate limits: External APIs may limit requests
When to Use
- Scientific Research: Search papers, studies, guidelines
- Fact Validation: Verify claims against authoritative sources
- Prices/Availability: Query real-time information
- External Compliance: Check published regulations
- Public Data Enrichment: Government APIs, datasets
Healthcare Example: S.2-1.2 - Scientific Reference Search
Function: Find scientific references to validate medical claims
Implementation Pattern (Clojure):
(ns lab.agents.scientific-search
"Type C: AI + Web Grounding - Scientific reference search"
(:require [lab.config.google-cloud :as gc])
(:import [com.google.cloud.vertexai.api Tool GroundingMetadata]))
(defn create-grounded-agent
"Creates Type C agent with grounding enabled."
[{:keys [project-id location grounding-sources]
:or {grounding-sources ["google_search" "google_scholar"]}}]
(let [vertex-ai (VertexAI. project-id location)
grounding-tool (-> (Tool/newBuilder)
(.setGoogleSearchRetrieval
(-> (GoogleSearchRetrieval/newBuilder)
(.build)))
(.build))
model-instance (-> (.getGenerativeModel vertex-ai "gemini-1.5-pro")
(.withTools [grounding-tool]))]
model-instance))
(defn search-scientific-references
"Searches scientific references with grounding."
[agent claims]
(let [prompt (format
"For each medical claim, search reliable scientific references.
Minimum 2 primary sources, 1 systematic review if available.
Sources: PubMed, Google Scholar, SciELO. Return JSON."
(json/generate-string claims))
response (.generateContent agent prompt)
text (-> response .getText)
grounding-metadata (.getGroundingMetadata response)]
(assoc (json/parse-string text true)
:grounding-sources (-> grounding-metadata .getSearchQueries vec)
:grounding-confidence (-> grounding-metadata .getConfidence))))
Real Metrics:
- Average time: 12.1s (8.2s grounding + 3.9s LLM)
- Average cost: $0.175
- Success rate: 91.7%
- References/claim: 4.3 average
- Important: Rate limiting on public APIs (PubMed: 3 req/s)
🔶 Type D: AI + CAG + Web (Maximum Context)
Definition
Input + Database Context + Web Grounding → LLM → Consolidated output
Agent combines all capabilities: accesses tenant DB AND performs external searches. Maximum possible context, used for final consolidation or complex decisions.
Characteristics
- ✅ Maximum context: Tenant DB + web + input
- ✅ Complex decisions: Multiple sources of truth
- ✅ Total compliance: Internal rules + external regulations
- ⚠️ Maximum latency: 15-20s total
- ⚠️ Maximum cost: $0.30-0.50 per execution
- ⚠️ High complexity: Orchestration of multiple sources
When to Use
- Final Consolidation: Aggregate data from multiple sources
- Critical Decisions: Require complete context
- Multi-Source Validation: Check against DB + web
- Executive Reports: Insights from internal + external data
- Total Compliance: Validate against internal rules + public regulations
Healthcare Example: S.4-1.1-3 - Final Text Consolidation
Function: Consolidate all previous outputs (LGPD data, validated claims, references, SEO) into final professional text ready for publication
Real Metrics:
- Average time: 16.8s (4.2s queries + 9.5s grounding + 3.1s LLM)
- Average cost: $0.42
- Success rate: 89.3%
- Trade-off: Maximum quality vs cost/latency
📘 Complete implementation: See
cva-healthcare-pipelineskill, System S.4.
📊 Selection Strategy (Decision Tree)
┌─────────────────────────────────────────┐
│ Need external data (web/APIs)? │
└─────────────┬───────────────────────────┘
│
┌─────┴─────┐
│ │
NO YES
│ │
v v
┌───────────┐ ┌─────────────────────────────┐
│ Need │ │ Need tenant DB also? │
│ tenant DB?│ └──────────┬──────────────────┘
└─────┬─────┘ │
│ ┌─────┴─────┐
┌───┴───┐ │ │
│ │ NO YES
NO YES │ │
│ │ v v
v v ┌────────┐ ┌────────┐
┌───┐ ┌───┐ │ TYPE C │ │ TYPE D │
│ A │ │ B │ │ │ │ │
└───┘ └───┘ └────────┘ └────────┘
Mapping Examples
| Task | Need DB? | Need Web? | Type | Justification |
|---|---|---|---|---|
| Extract entities from text | ❌ | ❌ | A | Direct input sufficient |
| Classify sentiment | ❌ | ❌ | A | Pure text analysis |
| Generate personalized text | ✅ | ❌ | B | Need profile/history |
| Validate tenant compliance | ✅ | ❌ | B | Rules in DB |
| Search scientific papers | ❌ | ✅ | C | External sources |
| Check real-time prices | ❌ | ✅ | C | Public APIs |
| Consolidate executive report | ✅ | ✅ | D | Internal + market data |
| Total regulatory validation | ✅ | ✅ | D | Internal + CFM/CRP rules |
💡 Best Practices
1. Always Start with Type A
"Premature optimization is the root of all evil" - Donald Knuth
Implement first as Type A. If output is unsatisfactory, consider B/C/D. Often, a well-structured Type A prompt is sufficient.
2. Context Caching (Type B)
DB contexts rarely change. Aggressive caching:
- Professional profiles: TTL 1h
- Regulations: TTL 24h
- SEO keywords: TTL 7 days
Observed savings: 85% query reduction
3. Batch for Type C
Grounding is expensive. Group multiple claims in a single call:
;; ❌ Inefficient: 5 calls
(doseq [claim claims]
(search-references agent [claim]))
;; ✅ Efficient: 1 call
(search-references agent claims)
Savings: ~70% cost and latency
4. Conditional Grounding (Type D)
Not always need web grounding. Use conditional logic:
(defn consolidate-content
[agent inputs]
(let [db-contexts (fetch-all-contexts inputs)
needs-grounding? (requires-external-validation? inputs)
web-data (when needs-grounding?
(perform-grounding inputs))]
(generate-final-content agent db-contexts web-data)))
5. Fallback Strategy
Grounding can fail (rate limits, timeout). Have fallback to Type B:
(defn robust-consolidation
[agent inputs]
(try
(consolidate-tipo-d agent inputs) ; Try with grounding
(catch Exception e
(log/warn "Grounding failed, falling back to Type B" e)
(consolidate-tipo-b agent inputs)))) ; Fallback without web
🎯 Executive Summary
| Aspect | Type A | Type B | Type C | Type D |
|---|---|---|---|---|
| Primary use | Analysis, extraction | Personalization | Research, validation | Consolidation |
| Latency | ~3s | ~5s | ~12s | ~17s |
| Cost | $0.02 | $0.08 | $0.18 | $0.42 |
| Complexity | ⭐ | ⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐ |
| Success rate | 96% | 95% | 92% | 89% |
| When to use | Default | Tenant context | External data | Critical decisions |
Recommended Distribution in Pipeline (Healthcare):
- Type A: 40% of systems (extraction, classification)
- Type B: 40% (personalization, compliance)
- Type C: 15% (scientific validation)
- Type D: 5% (final consolidation)
ROI Multi-Model + Typing:
- Savings vs "Type D everywhere": 67%
- Savings vs "Claude-only": 41%
- Average pipeline time: 34.2s (vs 87s all Type D)
🔗 Related Skills
cva-healthcare-pipeline- Practical application of all 4 types ⭐cva-patterns-cost- Cost optimization strategiescva-patterns-context- Context management (CAG) implementationcva-patterns-workflows- Multi-agent orchestration
📘 Additional Documentation
For detailed examples by type, see:
- Type A Examples - Pure AI implementations
- Type B Examples - CAG patterns
- Type C Examples - Grounding strategies
- Type D Examples - Maximum context consolidation
- Decision Tree - Visual selection guide
This taxonomy is validated in production with proven ROI. Use it to make systematic architecture decisions and optimize costs.
Recommended Agent Skills
Expand your agent's capabilities with these related and highly-rated skills.
agent-ops-spec
Manage specification documents in .agent/specs/. Use when user provides requirements, acceptance criteria, or feature descriptions that need to be tracked and validated against implementation.
agent-ops-state
Maintain .agent state files. Use at session start, after meaningful steps, and before concluding: read/update constitution/memory/focus/issues/baseline consistently.
agent-ops-spec
Manage specification documents in .agent/specs/. Use when user provides requirements, acceptance criteria, or feature descriptions that need to be tracked and validated against implementation.
agent-ops-testing
Test strategy, execution, and coverage analysis. Use when designing tests, running test suites, or analyzing test results beyond baseline checks.
agent-ops-testing
Test strategy, execution, and coverage analysis. Use when designing tests, running test suites, or analyzing test results beyond baseline checks.
agent-ops-state
Maintain .agent state files. Use at session start, after meaningful steps, and before concluding: read/update constitution/memory/focus/issues/baseline consistently.
Didn't find tool you were looking for?