Agentic Systems: A Three-Tier Conceptual Framework for Intelligent Information Processing

TLDR

Agentic systems—autonomous AI agents that perceive, reason, and act—can be understood through a three-tier conceptual framework analogous to how Turing machines formalize computation. Tier 1 establishes foundational concepts: information (measured by entropy and uncertainty) and intelligence (capacity to reduce entropy through reasoning). Tier 2 defines the functional architecture: input (data ingestion), processing (memory and context), reasoning (LLM-based intelligence), actions (tool execution and environment interaction), and output (structured results). Tier 3 details technical implementations: data pipelines for input, context windows and vector stores for processing, reasoning models (Claude, GPT-4), tool ecosystems (APIs, scripts, file tools, MCP), and domain-specific output formats (CSV/Excel for finance vs. generic markdown). Critically, the environment—all non-agent components (databases, APIs, execution platforms, user interfaces)—defines the boundary where agents act and observe. This framework reveals why financial agentic systems prioritize structured outputs (CSV, Excel) over narrative formats: investors need actionable data for models, not prose. Understanding these three tiers clarifies design trade-offs, architectural decisions, and why different agentic systems excel at different tasks.

Introduction: Toward a Unified Theory of Agentic Systems

In 1936, Alan Turing formalized computation through a simple conceptual model: a machine with an infinite tape, a read/write head, and a finite set of states. This abstraction—the Turing machine—became the theoretical foundation for all modern computing, from mainframes to smartphones. It didn't describe how to build computers; it described what computation is.

Today, we're witnessing an analogous moment with agentic systems. Autonomous AI agents that perceive their environment, reason about goals, execute actions, and learn from outcomes are proliferating across industries—coding assistants (Claude Code, Cursor), financial analysis (Agentii, Hebbia), customer support (Intercom AI), research automation (Elicit), and more. Yet we lack a unified conceptual framework for understanding what these systems are at a fundamental level.

This post proposes a three-tier conceptual framework for agentic systems, moving from abstract principles (information and intelligence) through functional architecture (input, processing, reasoning, actions, output) to concrete technical implementations (data pipelines, LLMs, tool ecosystems, output formats). This framework helps us understand:

• Why different agentic systems make different architectural choices
• What distinguishes effective agents from brittle chatbots
• How environment design determines agent capabilities
• Why domain-specific outputs (CSV for finance, code for development) outperform generic markdown

Let's build this framework from first principles.

Tier 1: Foundational Concepts — Information and Intelligence

Information: Entropy and Uncertainty

At the most fundamental level, agentic systems are information processors. To understand what this means, we turn to Claude Shannon's information theory: information is measured by entropy—the uncertainty in a message or system state.

Formal Definition: For a discrete random variable X with possible values {x₁, x₂, ..., xₙ} and probability mass function P(X), the Shannon entropy H(X) is:

High entropy means high uncertainty (many equally likely outcomes). Low entropy means low uncertainty (one outcome dominates).

Why This Matters for Agentic Systems: Before an agent acts, the environment is in a state of uncertainty. Consider a financial analyst asking an agent: "What drove Apple's Q3 revenue growth?" The agent faces massive uncertainty:

• Which documents contain the answer? (10-K, 10-Q, earnings transcript, analyst reports, news articles)
• Which sections within those documents? (MD&A, revenue tables, management commentary)
• Which time periods? (Q3 2024 vs. Q3 2025, fiscal vs. calendar quarters)
• Which revenue segments? (iPhone, Services, Wearables, total revenue)
• Which growth metrics? (YoY, QoQ, sequential, constant currency)

This uncertainty is the information entropy the agent must reduce through its actions (retrieval, reasoning, verification). A successful agent transforms high-entropy questions into low-entropy answers grounded in evidence.

Intelligence: Entropy Reduction Through Reasoning

If information is entropy, then intelligence is the capacity to reduce entropy through reasoning, pattern recognition, and decision-making under uncertainty.

Operational Definition: An intelligent system takes high-entropy inputs (ambiguous questions, noisy data, incomplete observations) and produces low-entropy outputs (precise answers, structured predictions, actionable decisions) through inference.

In traditional systems, entropy reduction is hardcoded: SQL queries reduce uncertainty by executing exact database lookups. Rule-based systems reduce uncertainty through predefined logic trees. But these approaches fail when uncertainty is irreducible through simple rules—when questions require reasoning across contexts, synthesizing contradictory sources, or generalizing from limited evidence.

LLM-Based Intelligence: Modern agentic systems achieve entropy reduction through Large Language Models (LLMs) that learned statistical patterns from vast corpora. When GPT-4 or Claude processes "What drove Apple's revenue growth?", it:

1. Decomposes the high-entropy question into lower-entropy sub-questions (revenue figures, growth calculations, causal drivers)
2. Retrieves relevant information from knowledge or external sources
3. Reasons about which information is authoritative, consistent, and relevant
4. Synthesizes a coherent answer that reduces uncertainty

This isn't perfect intelligence—LLMs hallucinate, make logical errors, and sometimes increase entropy by generating plausible but incorrect answers. But the key insight is that intelligence in agentic systems is measured by net entropy reduction: Does the agent's output reduce user uncertainty more than it introduces new uncertainty through errors?

The "Unknown Unknowns" Problem

A critical limitation of information-theoretic framing: you cannot measure the entropy of what you don't know exists. This is Donald Rumsfeld's "unknown unknowns" problem: information you don't know you're missing.

Example: An analyst asks "What are Apple's risk factors?" The agent can retrieve disclosed risks from the 10-K Risk Factors section (known knowns) and infer some risks from news and analyst reports (known unknowns). But it cannot identify risks that:

• Haven't been publicly discussed (unreported supplier vulnerabilities)
• Emerge from combinations of factors (interaction risks)
• Require domain expertise to recognize (subtle regulatory changes)

These unknown unknowns represent irreducible entropy—uncertainty the agent cannot reduce because it lacks the information or reasoning capability to even recognize the gap. This limitation is why human judgment remains critical in high-stakes domains: experts develop intuition for what questions aren't being asked.

Tier 2: Functional Architecture — The Five Components of Agentic Systems

Moving from abstract concepts to functional architecture, all agentic systems decompose into five core components: Input, Processing, Reasoning, Actions, and Output. These components form a processing loop where agents perceive, think, act, and communicate.

Component 1: Input Information

Definition: Input is the data, context, and signals an agent ingests from its environment to reduce uncertainty about the task at hand.

Key Characteristics:

1. Modality Diversity: Text (documents, queries, logs), structured data (tables, databases), audio (call transcripts), images (charts, screenshots), video (rarely in current agentic systems)

2. Temporal Scope: Real-time data (live market prices, breaking news), historical data (10-year financial records), cached data (preprocessed embeddings)

3. Information Density: High-density inputs (10-K filings with tables, footnotes, cross-references) vs. low-density inputs (keyword queries, simple prompts)

Challenges:

• Context Limits: LLMs have finite context windows (128K-200K tokens for Claude 3.5, 128K for GPT-4 Turbo). High-density financial documents (400-page 10-Ks) exceed these limits.
• Noise: Not all input is signal. Agents must filter irrelevant information, prioritize authoritative sources, and ignore distractions.
• Latency: Real-time inputs (breaking earnings news) require immediate processing, while historical analysis can tolerate batch retrieval.

Financial AI Example: When an analyst asks "What drove Apple's margin expansion?", the input includes:

• User query (natural language text)
• Historical context (prior analyses of Apple margins)
• Document corpus (10-K, 10-Q filings spanning multiple years)
• Structured data (income statements, segment financials)
• Real-time signals (recent earnings call transcript)

The agent must orchestrate retrieval across all these modalities to build sufficient context for reasoning.

Component 2: Processing (Memory and Context Management)

Definition: Processing is how agents store, organize, and retrieve information to maintain context across multi-step interactions.

Memory Types:

1. Working Memory (Short-Term): The LLM's context window—information actively available during the current reasoning step. Limited to 128K-200K tokens.

2. Episodic Memory (Medium-Term): Conversation history and session-specific context. Persists across turns within a session but cleared when the session ends.

3. Semantic Memory (Long-Term): Persistent knowledge stored externally—vector databases (Pinecone, Weaviate), document stores, structured databases. Accessed via retrieval rather than held in context.

Context Engineering:

Modern agentic systems use context engineering—deliberate design of what information enters the LLM's context window and how it's organized. Key techniques:

• Context Compression: Summarize prior turns to fit more history in limited context
• Selective Retrieval: Only load relevant historical context (not entire conversation history)
• Hierarchical Memory: Store high-level summaries in-context, detailed information externally
• Context Pruning: Archive stale information to dedicated files (ARCHIVE.md) and keep only active context

Financial AI Example: An analyst tracking Apple across quarters needs:

• Working Memory: Current quarter's earnings data (in LLM context)
• Episodic Memory: Questions and answers from this session (conversation history)
• Semantic Memory: Historical quarterly snapshots (stored in vector database, retrieved on demand)

Effective processing ensures the agent can reference Q2 2025 analysis when asked about Q3 2025 trends without re-processing all Q2 documents.

Component 3: Reasoning (LLM-Based Intelligence)

Definition: Reasoning is the agent's capacity to infer, deduce, and synthesize information to reduce entropy and answer questions.

LLM Reasoning Capabilities:

Modern LLMs (Claude 3.5 Sonnet, GPT-4 Turbo, DeepSeek-V3) exhibit several reasoning capabilities:

1. Deductive Reasoning: If Revenue = $100B and COGS = $60B, then Gross Profit = $40B (logical deduction)

2. Inductive Reasoning: Apple's margins improved Q1→Q2→Q3 → margins are trending upward (pattern generalization)

3. Abductive Reasoning: Margins improved and management cited "product mix shift" → product mix likely drove margin expansion (inference to best explanation)

4. Analogical Reasoning: Apple's margin expansion mirrors Microsoft's 2018 Services mix shift → similar dynamics may be at play (cross-domain transfer)

5. Multi-Step Planning: Break "Compare Apple vs. Microsoft margins" into: (1) retrieve Apple margins, (2) retrieve Microsoft margins, (3) calculate differences, (4) identify drivers, (5) synthesize comparison

Reasoning Models: Recent advances introduced reasoning-optimized models (DeepSeek-R1, OpenAI o1) that explicitly show chain-of-thought steps before answering. These models trade latency (5-10x slower) for accuracy (10-30% improvement on complex tasks).

Limitations:

• Hallucination: LLMs generate plausible but incorrect information when uncertain
• Logical Fallacies: Weak correlation/causation reasoning, confirmation bias, overconfidence
• Context Dependence: Reasoning quality degrades with context window saturation
• Domain Knowledge Gaps: Financial LLMs struggle with specialized accounting rules, obscure regulations, novel corporate structures

Financial AI Example: When asked "Did Apple's margin expansion justify the stock price increase?", the agent must:

1. Retrieve: Margin data, stock price data, valuation multiples
2. Reason: Calculate margin improvement → estimate earnings impact → compare to stock price change → assess if price move was justified by fundamentals
3. Synthesize: "Apple's margins improved 200bps QoQ, driving 8% EPS beat. Stock rose 12%, implying 4% attributable to multiple expansion beyond earnings surprise."

This requires multi-step quantitative reasoning, not just retrieval.

Component 4: Actions (Tools and Environment Interaction)

Definition: Actions are operations the agent executes to gather information, transform data, or affect the environment. Actions distinguish agents (autonomous actors) from chatbots (passive responders).

Tool Categories:

1. Retrieval Tools: Search databases, query APIs, fetch documents

   • Vector search (semantic similarity)
   • BM25 search (keyword matching)
   • SQL queries (structured data)
   • Web search (real-time information)

2. Computational Tools: Execute calculations, run code, process data

   • Python interpreter (pandas, numpy)
   • Spreadsheet functions (formulas, pivot tables)
   • Statistical analysis (regression, correlation)

3. File Tools: Read, write, edit documents

   • Markdown files (context persistence)
   • CSV/Excel (structured outputs)
   • Code files (scripts, automation)

4. Communication Tools: Interact with external systems

   • APIs (Bloomberg, FactSet, SEC EDGAR)
   • Webhooks (notifications, alerts)
   • MCP servers (standardized tool protocols)

Dynamic Tool Selection: Effective agents choose tools adaptively based on query characteristics:

• Numerical extraction → SQL query or table parser
• Conceptual exploration → vector semantic search
• Exact terminology → BM25 keyword search
• Real-time data → web search or API call

Financial AI Example: To answer "What was Apple's FCF margin last quarter?", the agent might:

1. Action 1: SQL query to structured database for Apple's cash flow statement
2. Action 2: If SQL fails, retrieve 10-Q filing and parse cash flow table
3. Action 3: Extract "Cash from Operations" and "CapEx" line items
4. Action 4: Calculate FCF = CFO - CapEx
5. Action 5: Calculate FCF Margin = FCF / Revenue
6. Action 6: Verify result against financial data provider (Bloomberg API)

Each action reduces entropy by narrowing uncertainty about the answer.

Component 5: Output Information

Definition: Output is the format and structure in which the agent communicates results to users or downstream systems.

Output Format Taxonomy:

1. Narrative Outputs: Natural language text, markdown documents, written reports

   • Strengths: Human-readable, flexible, explanatory
   • Weaknesses: Unstructured, hard to parse programmatically, not model-ready

2. Structured Outputs: CSV, Excel, JSON, XML, databases

   • Strengths: Programmatically parseable, model-ready, precise semantics
   • Weaknesses: Less human-friendly, requires schema design

3. Visual Outputs: Charts, graphs, dashboards, visualizations

   • Strengths: Pattern recognition, trend identification, intuitive
   • Weaknesses: Hard to extract precise numbers, not machine-readable

4. Code Outputs: Scripts, automation workflows, executable programs

   • Strengths: Reproducible, composable, extensible
   • Weaknesses: Requires technical expertise to interpret

Domain-Specific Output Requirements:

Different domains demand different output formats:

• Financial Analysis: CSV/Excel tables (portfolio managers need data for models, not narrative summaries)
• Software Development: Code files (developers need runnable scripts, not pseudocode)
• Legal Research: Structured briefs with citations (lawyers need precise references)
• Medical Diagnosis: Structured clinical notes (doctors need EHR-compatible outputs)

Why Finance Prefers CSV/Excel Over Markdown:

When an analyst asks "What are gross margins for 50 SaaS companies?", the ideal output is:

Not:

Why CSV Wins:

1. Model-Ready: Analyst pastes CSV directly into Excel financial model (no manual reformatting)
2. Scannable: 50 companies visible at a glance (vs. 5+ pages of prose)
3. Sortable: Click "QoQ_Change" column header to rank by margin improvement
4. Composable: CSV merges easily with other datasets (valuation multiples, revenue growth)

This is why output format isn't cosmetic—it determines whether agents integrate into professional workflows or remain isolated demos.

The Environment: Where Agents Meet Reality

Defining the Environment

In agentic systems, the environment is everything that is not the agent itself:

• Data Sources: Databases, APIs, document repositories, web content
• Execution Platforms: Cloud compute (AWS, GCP), orchestration (Kubernetes), sandboxes
• User Interfaces: Web dashboards, CLIs, Slack bots, API endpoints
• External Systems: Excel, financial models, CRM systems, trading platforms

The environment defines the boundary conditions for agent behavior—what data is accessible, what actions are permitted, what outputs are consumable.

Why Environment Design Determines Agent Capability

A brilliant agent architecture fails if the environment doesn't support its needs:

Example 1: Data Access Limits

An agent designed to analyze 400-page 10-K filings needs:

• Document storage with full-text search
• Parsing tools for tables and footnotes
• Metadata indices (filing date, company, section structure)

If the environment only provides summarized data, the agent cannot perform detailed analysis—no amount of sophisticated reasoning compensates for missing inputs.

Example 2: Tool Ecosystem Constraints

An agent designed to automate financial modeling needs:

• Excel API access (read/write spreadsheets)
• Python execution environment (run pandas/numpy)
• Database connections (query financial data)

If the environment sandboxes agents without Excel or Python, the agent cannot complete its task.

Example 3: Output Format Restrictions

An agent designed to generate investment memos needs:

• Markdown rendering (for narrative reports)
• CSV export (for data tables)
• PDF generation (for client deliverables)

If the environment only supports plain text, the agent's outputs lack professional formatting.

Environment Integration Strategies

Successful agentic systems carefully design agent ↔ environment interfaces:

1. Data Layer Integration

• Agentii Approach: Native integrations with SEC EDGAR API, earnings transcript providers, Bloomberg/FactSet APIs
• Benefit: Agents access authoritative financial data without manual uploads
• Trade-off: Requires maintaining integrations as external APIs evolve

2. Execution Platform Integration

• Claude Code Approach: Local filesystem access, shell script execution, git operations
• Benefit: Agents manipulate real development environments (not sandboxes)
• Trade-off: Security risks if agents execute malicious code

3. Output Format Integration

• Agentii Approach: Native CSV/Excel generation, Slack notifications, API endpoints
• Benefit: Outputs integrate directly into investor workflows (paste into models)
• Trade-off: Must maintain exporters for multiple formats (CSV, XLSX, JSON)

4. User Interface Integration

• Cursor Approach: Embedded agents within VS Code IDE
• Benefit: Agents see what developers see (syntax highlighting, git diffs, debugger output)
• Trade-off: Tightly coupled to specific IDE (can't easily port to other editors)

The pattern: agents are only as capable as their environment allows. Architectural brilliance in reasoning or tool selection cannot overcome environmental constraints.

Tier 3: Technical Implementations — Building Real Agentic Systems

Input Implementation: Data Pipelines and Context Engineering

Data Pipeline Architecture:

Modern agentic systems ingest data through multi-stage pipelines:

1. Ingestion: Fetch data from APIs, scrape websites, parse documents
2. Preprocessing: Clean text, extract tables, normalize formats
3. Embedding: Convert text to dense vectors for semantic search
4. Indexing: Store embeddings in vector databases (Pinecone, Weaviate)
5. Metadata Tagging: Annotate documents with dates, entities, sections

Context Window Strategies:

Handling inputs larger than LLM context windows:

• Chunking: Split documents into 512-token chunks, embed separately
• Summarization: Generate summaries of long documents, fit summaries in context
• Selective Retrieval: Retrieve only relevant sections (not entire documents)
• Hierarchical Context: Store document outline in-context, retrieve sections on demand

Example: Processing 400-Page 10-K Filings

1. Ingestion: Fetch 10-K from SEC EDGAR API (XML/HTML format)
2. Parsing: Extract sections (Risk Factors, MD&A, Financial Statements, Footnotes)
3. Table Extraction: Specialized parsers for financial tables (balance sheet, income statement)
4. Chunking: Split MD&A into 512-token chunks with 50-token overlap
5. Embedding: Generate embeddings using finance-tuned sentence transformers
6. Indexing: Store chunks in Pinecone with metadata (section, page, fiscal period)
7. Retrieval: When user asks about risks, retrieve only Risk Factors section chunks

Trade-off: Chunking loses document-level context (hard to reason across distant sections). Solution: Use agentic retrieval where agents decide which sections to retrieve across multiple rounds.

Processing Implementation: Memory Systems

Vector Databases (Semantic Memory):

• Pinecone: Managed vector database, 100ms p95 latency, automatic scaling
• Weaviate: Open-source, customizable schemas, hybrid search (vectors + keywords)
• Chroma: Lightweight, embedded vector store, good for prototyping

Document Stores (Episodic Memory):

• Markdown Files: Human-readable, version-controlled (git), lightweight
  • agent.md: Project context and architectural decisions
  • todo.md: Current tasks and progress
  • MEMORY.md: Lessons learned from failures
• JSON Stores: Structured session logs, conversation history
• Relational Databases: PostgreSQL for structured metadata (company IDs, filing dates)

Context Pruning Strategies:

After 100+ agent turns, context files grow too large. Pruning techniques:

• Time-Based: Archive decisions older than 3 months to ARCHIVE.md
• Relevance-Based: Use LLM to identify stale context and remove it
• Summarization: Compress 5,000-word decision log into 500-word summary

Example: Intelligence Hub Snapshots

Agentii's Intelligence Hub uses temporal snapshots for memory:

• Q1 2025 Snapshot: Apple's revenue, margins, risks, thesis (saved as structured JSON)
• Q2 2025 Snapshot: Updated metrics + delta analysis vs. Q1
• Q3 2025 Snapshot: Updated metrics + delta analysis vs. Q2

Agents retrieve snapshots as needed: "How did margins evolve Q1→Q3?" → retrieve three snapshots, compute trend.

Reasoning Implementation: LLM Selection and Orchestration

Model Selection by Task Type:

Different reasoning tasks favor different models:

• Complex Multi-Step Reasoning: DeepSeek-R1, OpenAI o1 (explicit chain-of-thought)
• Fast Single-Turn QA: Claude 3.5 Haiku, GPT-4o-mini (low latency, lower cost)
• Long-Context Analysis: Claude 3.5 Sonnet (200K context), Gemini 1.5 Pro (1M context)
• Code Generation: Claude 3.5 Sonnet (strong at code), GPT-4 Turbo (good but slower)

Multi-Model Orchestration:

Production systems often use multiple models:

• Orchestrator: Fast model routes queries to specialized agents
• Retrieval: Lightweight model generates search queries
• Reasoning: Heavy model (GPT-4, Claude Opus) performs complex analysis
• Synthesis: Medium model writes final answer

Example: Agentii's Multi-Agent Architecture

1. Orchestrator Agent (Claude 3.5 Haiku): Decomposes "Compare Apple vs. Microsoft" into subtasks
2. Retrieval Agent (Embedding Model): Fetches relevant financial documents
3. Extractor Agent (Specialized Model): Parses tables, extracts numbers
4. Verifier Agent (Claude 3.5 Sonnet): Cross-checks numbers across sources
5. Synthesizer Agent (Claude 3.5 Sonnet): Writes final comparative analysis

Each model is optimized for its specific task—fast models for routing, powerful models for reasoning.

Actions Implementation: Tool Ecosystems

Function Tools (Structured APIs):

LLMs can call functions with typed parameters:

LLM generates function call:

Script Tools (Shell Scripts):

For complex operations, agents execute bash scripts:

Agent executes: bash analyze-margins.sh AAPL Q3_2025

File Tools (Markdown and Data Files):

Agents read/write files for persistence:

• Read: cat agent.md to load project context
• Write: echo "Analysis complete" >> todo.md to log progress
• Edit: Use LLM to generate diffs for modifying existing files

API Tools (External Services):

Agents call external APIs:

• SEC EDGAR: Fetch 10-K, 10-Q, 8-K filings
• Bloomberg API: Real-time market data, financial metrics
• News APIs: Breaking financial news, sentiment analysis

MCP (Model Context Protocol):

Standardized protocol for tool interoperability:

• MCP Server: Exposes tools via unified API
• MCP Client: Agents connect to servers, discover tools dynamically
• Benefit: Tools work across all MCP-compatible agents (Claude, GPT-4, etc.)

Example: Agentii's Tool Ecosystem

• File Tools: Markdown files for project specs, context, memory
• Script Tools: Shell scripts for data validation, preprocessing
• API Tools: SEC EDGAR (filings), financial data providers (metrics)
• Function Tools: Typed Python functions for numerical calculations
• MCP: Planned integration for cross-platform tool compatibility

Output Implementation: Format Generation

Structured Data Generation:

Agents generate CSV/Excel through structured prompts:

Prompt:

Output:

Markdown Generation:

For narrative reports:

Prompt:

Output:

JSON API Responses:

For programmatic consumption:

Why Finance Needs Structured Outputs:

Financial workflows require model-ready data:

• Portfolio managers paste CSV into Excel models (no manual reformatting)
• Quant researchers ingest JSON via APIs (automated pipelines)
• Risk teams import tables into BI tools (Tableau, PowerBI)

Markdown narratives require manual extraction—acceptable for one-off research, unacceptable for systematic workflows at scale.

Limitations: When This Framework Doesn't Apply

This three-tier framework has important limitations:

1. Simplifies Complex Trade-offs

Real agentic systems face trade-offs this framework glosses over:

• Latency vs. Accuracy: Reasoning-optimized models (DeepSeek-R1) achieve higher accuracy but 5-10x slower than fast models. Framework doesn't quantify this trade-off.
• Cost vs. Performance: Using GPT-4 for all tasks achieves best results but 10-30x higher cost than using GPT-4o-mini selectively. Framework doesn't provide cost models.
• Generality vs. Specialization: General-purpose agents handle diverse tasks but underperform domain-specific agents on specialized problems. Framework doesn't model this spectrum.

2. Underestimates Engineering Complexity

Moving from conceptual framework to production system requires solving hard engineering problems:

• Error Handling: What happens when API calls fail, LLMs hallucinate, or tools return malformed outputs?
• Concurrency: How do multiple agents coordinate when accessing shared resources (databases, file systems)?
• Security: How do you prevent agents from executing malicious code, leaking sensitive data, or accessing unauthorized resources?
• Monitoring: How do you observe agent decision-making, debug failures, and measure performance?

The framework describes what agentic systems do, not how to make them reliable in production.

3. Assumes Reliable LLMs

The framework assumes LLM reasoning is reliable enough for Tier 2 to work. In reality:

• LLMs hallucinate (generate false information confidently)
• LLMs suffer from recency bias (prioritize recent context over earlier context)
• LLMs make logical errors (invalid deductions, weak causal reasoning)
• LLMs lack common sense (accept absurd premises, miss obvious contradictions)

Production systems must add verification layers not captured in the framework—multi-source validation, business logic checks, human-in-the-loop review.

4. Oversimplifies Environment Dynamics

Treating the environment as static ignores dynamic challenges:

• Data Drift: Financial data sources change formats, APIs deprecate, document structures evolve
• Schema Evolution: Database schemas change, breaking SQL queries
• Access Control: API rate limits, authentication expiration, permission changes
• External Dependencies: Third-party services go down, network failures, timeouts

Real systems must adapt to evolving environments—the framework treats environment as fixed.

5. Doesn't Address Multi-Agent Coordination

The framework focuses on single-agent systems. Real deployments often use multiple agents collaborating:

• How do agents share information without duplicating work?
• How do agents resolve conflicts when they reach contradictory conclusions?
• How do agents coordinate access to shared resources (databases, APIs)?
• How do agents maintain consistency across distributed state?

Multi-agent coordination is a complex topic the framework deliberately avoids.

When to Ignore This Framework:

• Building simple chatbots (no need for Tier 2 decomposition)
• Prototyping with off-the-shelf tools (framework over-engineers simple use cases)
• Domains where environment is too dynamic to model (high-frequency trading, real-time controls)
• Applications requiring real-time guarantees (framework assumes asynchronous processing)

Disclosure

Author: Frank Zhang, Engineering Lead at Agentii.ai, with 8+ years building multi-agent systems for financial applications.

Holdings: No financial holdings in companies mentioned (Anthropic, OpenAI, Google, Bloomberg, FactSet, Hebbia, Fintool) as of publication date.

Conflicts of Interest: Agentii.ai implements agentic systems using patterns described in this framework. This analysis benefits from internal product knowledge but may be biased toward architectures we've found effective. We have attempted to present general principles accurately but recommend independent evaluation.

Methodology: This framework synthesizes:

• Academic Research: Information theory (Shannon 1948), computational theory (Turing 1936), agent architectures (Russell & Norvig 2020)
• Industry Practice: Agentic system implementations (Claude Code, Cursor, Agentii, Hebbia)
• Internal Development: 50+ agentic features shipped at Agentii in 2025
• Public Documentation: LangChain, LangGraph, Anthropic, OpenAI technical papers

Timestamp: Framework reflects state of agentic systems as of Q4 2025. Rapid evolution means some details may be outdated by Q2 2026.

Risk Factors: Framework may be incorrect if:

• LLM capabilities plateau (framework assumes continued reasoning improvements)
• New architectures emerge that don't fit three-tier model (quantum agents, neuromorphic systems)
• Regulatory restrictions limit agentic capabilities (AI safety regulations, liability concerns)
• Economic factors make compute costs prohibitive (energy prices spike, GPU shortages persist)

Disclaimer

Educational Purpose Only: This content is for educational and informational purposes only. It does not constitute:

• Professional engineering advice or recommendations to adopt specific architectures
• Endorsement of any specific vendor, platform, or technology
• Investment advice or solicitation to purchase AI-related products

No Warranties: Content provided "as is" without warranties of accuracy, completeness, or fitness for any particular purpose.

Independent Evaluation Required: Readers must conduct independent technical evaluation, consult experienced engineers, and validate frameworks against their specific requirements before making architectural decisions.

FAQ

Q: How does this framework differ from traditional software architecture models?

A: Traditional software architectures (MVC, microservices, event-driven) focus on deterministic systems where outputs are predictable given inputs. Agentic systems are non-deterministic—LLMs introduce stochasticity, reasoning paths vary, and outputs change across runs even with identical inputs.

The three-tier framework explicitly models information entropy (Tier 1) and reasoning under uncertainty (Tier 2)—concepts absent from traditional architectures because deterministic systems don't face these challenges.

Q: Why is "environment" considered separate from the agent rather than part of Tier 2?

A: The agent-environment boundary is a critical design choice. Environment encompasses all components the agent observes and acts upon but does not control:

• Databases (agent queries but doesn't own schema)
• APIs (agent calls but doesn't implement)
• User interfaces (agent outputs to but doesn't render)

Including environment in Tier 2 (agent architecture) blurs this boundary. By treating environment separately, we clarify which limitations stem from agent design vs. environmental constraints.

Example: An agent designed to generate Excel files cannot succeed if the environment lacks an Excel API. The failure isn't an agent architecture problem—it's an environment integration problem.

Q: Can this framework apply to non-financial domains (e.g., healthcare, legal, software development)?

A: Yes, the framework is domain-agnostic. The three tiers (Information/Intelligence, Functional Architecture, Technical Implementation) apply across domains:

Healthcare:

• Tier 1: Patient data (high entropy), diagnostic reasoning (entropy reduction)
• Tier 2: Medical records (input), EHR systems (processing), clinical reasoning (LLM), treatment recommendations (actions), structured clinical notes (output)
• Tier 3: HL7 FHIR APIs (input), vector databases (processing), medical LLMs (reasoning), prescription APIs (actions), EHR-compatible outputs

Legal:

• Tier 1: Case law (high entropy), legal analysis (entropy reduction)
• Tier 2: Legal databases (input), case management (processing), precedent analysis (reasoning), brief generation (actions), structured legal memos (output)
• Tier 3: Westlaw/LexisNexis APIs (input), document stores (processing), legal LLMs (reasoning), citation tools (actions), court-filing formats (output)

The domain-specific aspects are Tier 3 implementations—healthcare needs FHIR, legal needs Westlaw, finance needs SEC EDGAR.

Q: How do I decide whether my use case needs an agentic system or a simpler chatbot?

A: Use this decision tree:

Choose Simple Chatbot if:

• Single-turn questions with deterministic answers (FAQ, knowledge lookup)
• No multi-step reasoning required
• Errors are low-stakes (wrong answer = minor inconvenience)
• Cost/latency constraints are tight

Choose Agentic System if:

• Multi-step reasoning across documents/sources
• Complex workflows (retrieve → analyze → verify → synthesize)
• High-stakes decisions (errors cost thousands to millions)
• Need for transparency (show reasoning, cite sources)

Example: "What is Apple's ticker symbol?" → Chatbot (single lookup, deterministic)

Example: "Should I invest in Apple based on Q3 results?" → Agentic system (retrieve filings, analyze margins, assess risks, compare to peers, synthesize recommendation)

Q: Why does the framework emphasize CSV/Excel outputs for finance but markdown for other domains?

A: Domain workflows determine output format requirements:

Finance: Investors paste data into Excel models, run DCF valuations, build portfolio trackers. They need structured, model-ready data (CSV, Excel, JSON).

Software Development: Developers need executable code (.py, .js files), not prose descriptions of what code should do.

Legal: Lawyers need structured briefs with citations (specific case law references, statute numbers), not general summaries.

General Knowledge: Users asking about history, science, or concepts benefit from narrative explanations (markdown, HTML).

The framework emphasizes output formats must match downstream workflows—finance = structured data, code = executable files, legal = citations, general = narratives.

Q: How does this framework account for emerging standards like MCP (Model Context Protocol)?

A: MCP sits at Tier 3 (Technical Implementation) as a standardized protocol for agent ↔ tool communication.

Before MCP: Each agentic system implemented custom tool protocols (LangChain tools, OpenAI function calling, Anthropic tool use). Tools built for one system didn't work with others.

With MCP: Tools expose a standardized interface. Any MCP-compatible agent can discover and use any MCP tool without custom integration.

Framework Perspective: MCP is an implementation choice for Tier 2's "Actions" component. It doesn't change the conceptual need for agents to execute actions—it standardizes how those actions are exposed.

When MCP Matters: Large organizations with 100+ internal tools needing governance and cross-platform compatibility.

When MCP Doesn't Matter: Small teams using 5-10 tools where custom integrations are simpler than standing up MCP servers.

Q: What's missing from this framework that would make it more complete?

A: Several critical dimensions are under-explored:

1. Agent Learning and Adaptation: The framework treats agents as static (fixed models, fixed tools). Real systems should learn from failures, adapt to user preferences, and improve over time.

2. Multi-Agent Coordination: The framework focuses on single-agent systems. Production deployments often use agent swarms with coordination protocols.

3. Verification and Trust: The framework mentions verification but doesn't formalize how to verify agent outputs, measure confidence, or decide when human oversight is required.

4. Cost Modeling: The framework doesn't quantify trade-offs between model quality (GPT-4 vs. GPT-4o-mini), tool complexity (SQL vs. vector search), and operational costs.

5. Failure Modes: The framework describes success paths but under-specifies failure recovery—what happens when LLMs hallucinate, APIs fail, or tools return malformed outputs?

Future refinements should address these gaps.

Read Next:

• Agentii.ai vs. The Financial AI Landscape: Architecture, Use Cases, and Strategic Positioning
• The 2025 Agentic Framework Evolution: From Rigid Tools to Intelligent Collaboration
• Achieving 99% Accuracy in Financial AI: Why Agentii Chose Agentic Search Over RAG