AI Agents: Framework vs. Platform — The Line Between Building an AI Agent and Declaring One

A software engineer’s guide to the ownership behind copilots, custom agents, and agentic applications.

The confusion is real — and it’s costing engineers clarity and obscures the engineering

Spend enough time in engineering discussions about AI, scroll through any internal Slack channel, job posting, or LinkedIn post about AI and we hear the same sentence describing very different work: “I built an agent.”

A developer who spent an afternoon writing a Copilot custom agent — a markdown file with instructions and a list of allowed tools — will say “I built an agent.” A developer who spent three weeks designing a LangGraph state machine with retry logic, custom memory persistence, and failure-recovery branches will say exactly the same sentence. Both are technically correct. Both are describing wildly different amounts of engineering ownership.

I have seen this confusion firsthand while helping AI adoption across multiple multi-stack accounts each with 500+ engineers team spanning over different demography. In one of the example: A staffing discussion nearly assigned agent-development work to someone whose experience was configuring Copilot agents for pull-request summaries. That was useful experience. But the assignment required a stateful orchestration pipeline spanning three internal systems that had never worked together. The terminology matched; the demonstrated capability did not.

In this article, I will try to draw that line as it matters before diving deep into multi-agent orchestration, memory, governance, or production readiness. Otherwise, every conversation begins with a different understanding of what has actually been built.

A declarative platform agent specializes an existing execution system. A custom agentic application makes the team responsible for selecting, assembling, and governing the execution system around the model.

That is the line worth drawing. It is a line of responsibility, not a ranking of developer competence or product sophistication.

First, separate the terms that keep getting mixed together

“Copilot” can describe a product brand or a user experience in which AI assists a person. It does not specify the underlying execution architecture. A copilot can offer suggestions, carry out a predefined workflow, or perform adaptive, multi-step work.

“Claude” also needs qualification. Calling a Claude model through an API and configuring a Claude Code subagent operate at different layers. In this article, the platform examples are GitHub Copilot custom agents and Claude Code subagents, rather than every product or feature carrying those brands.

“Agentic” concerns how work proceeds. Anthropic offers a useful architectural distinction: workflows follow predefined execution paths, while agents allow the model to direct the process and tool use dynamically. This is a useful working definition, rather than a universally enforced industry standard

An application that always retrieves documents, summarizes them, and returns an answer is an AI workflow. An application that investigates a failed build, chooses a diagnostic tool, observes the result, and changes its next action exhibits agentic behavior.

Both may call the same model. Both may be implemented with the same framework. The difference is how the next action is selected.

Fun fact: The word “agent” in AI didn’t originate with LLMs at all. It comes from 1980s distributed-AI research on autonomous software entities that perceive an environment and act on it — the formal definition (Russell & Norvig’s “anything that perceives its environment and acts upon it”) predates ChatGPT by roughly three decades. The LLM boom didn’t invent the concept; it just gave millions of developers a reason to argue about it.

Two constructs, precisely defined

Rather than describing these by behaviours, let’s describe them by what they actually are, mechanically.

A declarative platform agent

This is what you get inside GitHub Copilot’s custom agent framework, or Claude’s subagents and Skills. You author a configuration artifact — typically markdown with YAML frontmatter — that declares:

• A system persona and instructions
• A scoped list of tools the agent may call
• Conditions under which the platform should invoke it

The platform owns everything else: the reasoning loop that decides when to call a tool, the sandbox that actually executes the tool call, session state, and error recovery. You are extending a runtime you did not write and cannot inspect below the configuration layer.

A custom agentic AI solution

This is what you get when you call an LLM API (Claude, GPT, open-weight models) directly and wrap it in your own orchestration code — LangGraph, Semantic Kernel, or a hand-rolled loop. Here, the model is invoked purely as a reasoning engine. Everything around it is yours to design and yours to fix when it breaks:

• The control flow (when to call the model again, when to call a tool, when to stop)
• Tool schemas and the actual execution of each tool call
• Memory and state persistence across turns or sessions
• What happens when a tool call fails, times out, or returns something unexpected
• State management & RAG capability

Same underlying ingredient — an LLM API call — completely different amount of surrounding engineering.

What a declarative custom agent actually customizes

A declarative platform agent is a specialization interpreted by an existing host. Its configuration can describe a role, instructions, available tools, and other supported behavior.

GitHub Copilot custom agents use Markdown content and YAML frontmatter. GitHub documents tool selection, including tools supplied through MCP servers, and notes differences between execution environments. The profile defines a specialization; the host supplies the main execution machinery. GitHub: Custom agents configuration.

Claude Code subagents provide another example. They have separate context windows, custom system prompts, tool access, and permission configuration. These are substantive execution capabilities, not simply a persona attached to a chat. Their configuration and permission semantics are specific to Claude Code. Claude Code: Create custom subagents.

Creating an effective specialization can require considerable engineering judgment: expressing domain rules, selecting tools, shaping context, building integrations, and evaluating outcomes. The configuration author benefits from an execution system already supplied by the platform.

“Declarative” describes how the specialization is expressed. It does not mean that the resulting behavior is simple. A Kubernetes manifest can initiate a complex deployment without containing a scheduler implementation. Similarly, an agent profile can activate sophisticated behavior without implementing the runtime that makes it possible.

What changes in a custom agentic application

In a custom application, the team takes responsibility for the composition around the model: control flow, tool contracts, state, failure handling, access controls, and operational behavior. It may implement these directly or adopt them from a framework or managed runtime.

That qualification matters. Building a custom application does not require writing every loop, checkpoint, or retry mechanism from scratch. It requires understanding which components provide those capabilities and whether their guarantees satisfy the application’s requirements.

LangChain provides higher-level abstractions and integrations for models, tools, and agent loops; its agents are built on LangGraph. LangGraph focuses on orchestration capabilities such as persistence, durable execution, and human intervention, and supports combining deterministic and model-directed steps. The two operate at related but different levels. LangChain overview, LangGraph overview.

Semantic Kernel also provides abstractions for incorporating agentic patterns into applications. Microsoft now identifies Microsoft Agent Framework as the direct successor to Semantic Kernel and AutoGen. Framework names evolve; the responsibility for understanding the application’s behavior remains. Semantic Kernel Agent Framework, Microsoft Agent Framework overview.

Importing one of these libraries does not establish autonomy or production readiness. A framework can supply persistence mechanisms. The application still needs an appropriate state design and a recovery strategy for operations outside that state store.

The diagnostic test that actually resolves the confusion

Forget feature checklists. Both constructs can have “memory,” “tools,” and “multi-step reasoning” — that’s exactly why people conflate them. The question that actually separates them is about ownership, and it’s falsifiable:

If the orchestration loop broke in production at 2 a.m., could you open the code and fix it — or would you be filing a support ticket with a vendor?

If you built the loop, you fix the loop. If the platform built the loop, you wait for the platform’s next release, or you route around the limitation with more configuration. Neither answer is shameful — but only one of them is framework-level systems engineering, and pretending otherwise is where the career-planning damage happens.

Comparative anatomy: where responsibility sits

The visual model

Both paths converge at exactly one point — the LLM reasoning call — and diverge everywhere else. That convergence point is the entire argument compressed into one diagram: everything that determines engineering ownership, cost, and risk sits outside the box both paths share.

Fun fact: This exact ownership gap is why “agentic coding assistant” benchmarks vary so wildly between vendors — some measure the platform’s built-in failure recovery, others measure a raw model’s tool-calling accuracy with no orchestration scaffolding at all. They’re not measuring the same layer of the stack, even when the marketing language is identical.

Worked example: the same task, built two ways

Consider a reviewer that reads a pull-request diff, checks it against a team style guide, and posts actionable comments.

The platform approach

The team defines a review specialization, supplies the style guide, and makes the necessary reading and commenting capabilities available through supported integrations and permissions. Its instructions might say about intent, steps, guardrails, output format etc.

The host supplies the main model-and-tool cycle. The team shapes its behavior and tests whether the results are useful. Comment publication still depends on the host’s capabilities, the configured integration, and the caller’s permissions.

The instruction “do not merge” expresses intent. Removing merge authority from the available execution path provides a stronger boundary. Prompt wording and enforced capability restrictions do different jobs.

The application approach

The team defines how the review runs: how to identify a revision, retrieve context, invoke the model, validate proposed comments, publish them, and record completion. A framework may provide the execution scaffolding, while custom code defines the application-specific behavior.

If the sequence is always “fetch, analyze, validate, publish,” it is a workflow — even if implemented in LangGraph. It becomes more agentic when the model can choose further investigation, such as inspecting a referenced file or checking a related test before deciding whether to comment.

The observable result may look identical in both implementations. The engineering contribution is revealed by the execution decisions and guarantees behind it.

Failure handling makes the ownership gap visible

Suppose comment publication fails. The pull request may have closed, a credential may have expired, or a network timeout may have hidden a successful write. These situations should not necessarily receive the same response.

In a custom application, the team can design distinct branches: stop an obsolete review, refresh credentials through an approved mechanism, or check whether a comment already exists before retrying. The team must also verify that its chosen runtime supports that design.

In a platform implementation, the available response depends on the host and its extension points. A custom tool or backend may implement recovery logic. The host may expose relevant controls. If the required behavior is unavailable at those boundaries, additional prompting cannot create the missing execution guarantee.

That is a more accurate distinction than saying platform agents cannot handle failures. The question is whether the required behavior is expressible and enforceable at a boundary your team controls.

A successful write followed by a crash

Imagine the comment was posted successfully, but the worker crashed before recording completion. On restart, repeating the operation could post it again.

A prompt saying “never duplicate comments” does not resolve that ambiguity. The design needs a suitable mechanism — perhaps an idempotency key where supported, a durable operation identity, or reconciliation against the external system. A checkpoint alone does not make an external side effect exactly once.

These are deductions from the example’s failure conditions, rather than claims about a particular product. They show why engineering ownership becomes visible when the happy path ends.

Why this matters beyond terminology

For engineers: this is a direct capability question. Platform-configuration experience is genuinely useful and worth having — it’s fast, low-risk, and solves real problems. But it does not, by itself, transfer to framework-level system design. If your only “agent” experience is declarative config, you haven’t yet done the work that agentic system architecture actually requires: state design, failure semantics, memory architecture. That’s not a criticism — it’s a gap you can close, but only once you can see it.

For architects: this is a build-vs-configure decision with real cost and governance consequences. Declarative agents are cheap and fast but bounded by the platform’s ceiling. Custom agentic solutions are expensive to build but unbounded — the right call depends entirely on whether your workflow lives entirely inside one platform’s surface or needs to reach across systems the platform was never built to touch.

For leadership: “agent experience” on a resume or in a project retro means almost nothing without knowing which path someone actually worked in. Two people can list the identical bullet point — “built a customer-support agent” — and have done fundamentally different engineering work.

Moreover, this understanding also extends beyond design decisions: it helps identify the mix of skills a team needs to build, operate, and maintain the solution.

A decision framework, not just a moral

Reach for a declarative platform agent when:

• The workflow lives entirely inside the platform’s existing surface (an IDE session, a chat window)
• Your tool needs match the platform’s existing connector catalog
• Speed to first working version matters more than customization depth

Reach for a custom agentic solution when:

• The workflow needs to reach across systems the platform doesn’t already connect to
• You need custom failure handling, retries, or human-approval gates the platform doesn’t expose
• You need to remain model-agnostic, or deploy the capability outside any single platform’s session

The line worth remembering

A Markdown profile can activate a capable agent. A Python application can remain a fixed workflow. More agents do not automatically mean better coordination, and a stronger model cannot supply a missing authorization check or repair an unreliable recovery design.

For engineers going deeper into AI, the foundational understanding is the system around the model: what selects the next action, what executes it, what state survives, and what prevents an inappropriate operation.

The next time someone says, “We built an agent,” ask the question that gives the claim technical meaning:

What did we configure, what did we implement, and which execution guarantees are we relying on someone else to provide?

That answer tells us what has actually been engineered — and what the team is prepared to own when it breaks.