Blog - Published: Thursday, 2026-07-09 12:00 UTC
The model is only one dependency.
Writing AI applications quickly teaches a humbling lesson: the hard part is rarely just sending text to a model. Useful AI products depend on a network of external systems: model APIs, databases, document stores, source feeds, authentication providers, email services, search indexes, webhooks, background jobs, and now tool interfaces such as MCP servers.
That dependency graph is where AI products become real. It is also where they can break. Every external call introduces latency, cost, permissions, failure modes, data movement, security concerns, and operating responsibilities.
Pre-AI software
Applications became networks of services
Modern software has long depended on external systems: databases, payment processors, email providers, authentication services, search engines, storage layers, and third-party data feeds. AI applications inherit that same dependency graph.
2000
REST made networked resources a dominant pattern
Roy Fielding's REST architectural style helped define how network-based software could expose resources through uniform interfaces. That thinking shaped the web API era that AI applications now build on.
2010s
API contracts became infrastructure
JSON-RPC, OpenAPI, GraphQL, webhooks, SDKs, and typed schemas made integrations more formal. Instead of guessing how to call a service, applications could describe operations, parameters, responses, and errors.
2023 and after
Models began asking applications to use tools
Tool and function calling turned model output into structured requests. The model can suggest a tool call, but the application still executes code, checks permissions, handles errors, and returns the tool result.
2024 and after
MCP standardized a new AI integration layer
Anthropic introduced the Model Context Protocol in November 2024 as an open standard for connecting AI assistants to the systems where data lives. MCP reframes integration as hosts, clients, servers, tools, resources, and protocol-level messages.
The external-call loop
AI orchestration is often a loop: define the task, select allowed tools, build bounded context, ask the model to decide or call a tool, validate the request, execute application-owned code, return the result, and log the trace. The model can request an action, but the application owns the action.
That distinction is essential. Tool calling and MCP do not remove software engineering. They make software engineering more visible: schemas, permissions, input validation, error handling, idempotency, and audit logs become part of the AI product.
Define the task
Select allowed tools
Validate user access
Build bounded context
Ask model to plan or call
Validate tool arguments
Execute with timeouts
Return structured result
Generate final output
Log cost and trace
Core concepts
External dependency
Any system the AI application depends on outside the model call: databases, LLM provider APIs, email systems, search indexes, storage buckets, payment systems, data feeds, MCP servers, and internal services.
API call
A structured request to another system. In AI apps, API calls often retrieve evidence, save state, estimate cost, send alerts, create artifacts, or call model providers.
Tool calling
A model returns a structured tool request, but application code decides whether to execute it, how to validate inputs, and what result to return to the model.
MCP server
A service that exposes context, resources, or tools to an AI host through the Model Context Protocol. It can make integrations more reusable, but it also creates a new trust boundary.
Auth and authorization
Authentication proves who or what is calling. Authorization decides what that caller can access or do. AI systems need both before retrieval or tool execution.
Reliability engineering
External calls fail. Production AI systems need timeouts, retries, fallbacks, idempotency, rate-limit handling, queueing, and graceful degradation.
Observability
The system needs logs, traces, cost records, model call summaries, response timing, failure reasons, and audit trails so behavior can be explained after the fact.
Human control points
The more power tools have, the clearer the approval boundary must be. Drafting can be automated sooner than sending, publishing, deleting, or modifying production data.
How this applies to IntelliOS today
IntelliOS is not just a model prompt. It is a full-stack application with a browser UI, server routes, database reads and writes, report parsing, model provider APIs, token accounting, source monitoring, generated pages, email-oriented workflows, and browser verification. Each piece depends on external or boundary-crossing calls.
This is why building IntelliOS created practical experience in AI application architecture. The work was not only about asking a model to produce threat intelligence. It was about designing the interfaces around the model so evidence, permissions, costs, and outputs remain manageable.
Important boundary
This article describes architecture and learning at a product level. It does not disclose private prompts, environment values, API keys, access tokens, private credentials, proprietary scoring details, or sensitive operational internals.
LLM provider APIs
IntelliOS relies on model provider APIs for structured extraction, grounded chat, synthesis, and intelligence drafting. That makes model routing, provider fallback, token estimation, and usage logging part of the architecture.
Future application: A future version can route each task to the most appropriate model based on sensitivity, context length, cost, latency, and required reasoning depth.
Supabase and SQL data access
Reports, chunks, chat records, usage ledgers, user access, source metadata, and product state depend on the database layer. The AI feature is only useful if the retrieval and persistence layers are reliable.
Future application: A richer retrieval layer can combine SQL filters, full-text search, vector search, source-tier logic, recency, and duplicate suppression.
Next.js API routes
IntelliOS uses API routes to separate browser actions from server-side work: ingestion, chat, estimates, access checks, alerts, admin operations, and workspace workflows.
Future application: As agents become more capable, route handlers can enforce tool permissions and produce consistent traces before any model sees sensitive context.
Email and alert systems
Alert workflows depend on external delivery infrastructure. The AI output is only one part of the workflow; subscription rules, run logs, dedupe, and delivery outcomes also matter.
Future application: Future agent workflows can draft alerts automatically while requiring review before high-impact customer notifications.
Document and source ingestion
PDF parsing, HTML article preparation, source monitoring, and report chunking are dependency-heavy workflows. Each step can fail, produce partial data, or need review.
Future application: MCP servers could expose document repositories, source trackers, or controlled search indexes as standard tools for retrieval and ingestion agents.
AI-assisted development
Building IntelliOS with an AI coding agent also highlighted the external-dependency problem: the agent had to inspect files, run commands, call tools, read logs, and verify pages through browser automation.
Future application: A mature internal development agent could use approved MCP servers for issue tracking, repository context, deployment logs, database diagnostics, and browser QA.
Where MCP fits
MCP is useful because it standardizes how AI hosts connect to external context and capabilities. Instead of building one custom integration for every assistant and every source, an organization can expose a capability once through a server and let approved clients use it through a known protocol.
For IntelliOS, the right near-term MCP pattern would be controlled and narrow: read-only retrieval first, scoped actions second, and write-capable tools only after permissions, logging, and human approval are mature.
APIs versus MCP servers
A REST API or RPC endpoint usually exposes application functionality directly to code. An MCP server exposes tools, resources, and prompts to AI applications through a protocol designed for model-connected workflows.
They are complementary. An MCP server may call existing internal APIs behind the scenes. The important design choice is where to enforce permissions, how to log calls, and what shape of result the agent is allowed to receive.
Future MCP patterns for IntelliOS
Report corpus MCP server
Expose approved report search, report metadata, chunk retrieval, and citation lookup as read-only MCP tools for internal agents.
Source monitoring MCP server
Let agents query monitored publisher pages, retrieve latest candidates, compare source state, and return structured deltas without direct database writes.
Workspace notification MCP server
Expose notification drafting and subscription-state lookup while keeping send permissions behind a human approval gate.
Evaluation harness MCP server
Allow agents to run approved regression checks, inspect results, and propose fixes without granting unrestricted shell or production access.
Publisher intake MCP server
Provide controlled tools for checking duplicates, validating source metadata, staging an article, and preparing a human-reviewed ingest package.
Incident diagnostics MCP server
Expose read-only traces, recent failures, queue status, and route health so an operations agent can explain what failed and recommend a next step.
Dependency risks to design around
Dependency failure
External APIs can be down, slow, rate-limited, or return malformed data. AI workflows need timeouts, retries, fallback paths, and clear user-facing errors.
Credential exposure
Keys and tokens are the bridge to external systems. They should stay out of prompts, logs, screenshots, public pages, and generated output.
Over-permissioned tools
An agent with broad write access can turn a reasoning error into a real operational incident. Start with read-only tools and expand carefully.
Data leakage
External calls can move private data across boundaries. Retrieval and tool execution should enforce access before context is sent to a model or server.
Hidden cost growth
Every model call, retrieval call, and external API request can add cost. Token estimation, usage ledgers, and run-level accounting make the system manageable.
Unreviewed autonomy
The architecture should define which actions are autonomous, which are draft-only, and which require a person before the action is committed.
The takeaway from building IntelliOS
AI applications are not self-contained model demos. They are dependency-aware software systems. The model interprets and reasons, but external services provide the data, actions, persistence, delivery, monitoring, and operational reality.
IntelliOS made that concrete: grounded intelligence requires model APIs, report stores, search and retrieval, server routes, token ledgers, source monitoring, alert paths, and verification tooling. MCP servers can make that ecosystem more standardized in the future, but the same engineering duties remain: least privilege, reliability, observability, cost control, and human oversight.