Can AI Agents Build and Run Applications? A Practical Experiment
Can AI agents actually build and run real applications? We examine what happens when an AI coding agent gets access to a real execution environment through MCP, using Causly Server as a working example.
- 1.Can AI Agents Build and Run Applications? A Practical Experiment
- 2.How Much Can an AI Agent Build Without Human Intervention?
- 3.What Happens When an AI Agent Gets Stuck?
- 4.When Is an AI Agent Actually Done?
Most AI coding demos stop at the same place: the model generates some code.
That's useful, but it leaves out the harder part.
What happens when the AI agent needs to read files, change a project, interact with external systems, provision infrastructure, run checks, and keep going after something fails?
At that point, the problem is no longer just code generation. The agent needs an environment where its actions can actually happen.
For this research, we're looking at that boundary through Causly Server, an open-source MCP server that exposes real system capabilities to AI clients such as Claude. The goal isn't to claim that an AI agent can magically build an entire production application by itself.
Instead, we're asking a more useful question:
What capabilities become possible when an AI agent is connected to an actual execution environment?
The Experiment
For this experiment, Causly Server was running locally on the developer's machine and connected to Claude through MCP. Claude could discover and call the tools exposed by the server, while Causly Server performed those operations in the connected environment.
Claude
│
│ MCP
▼
Causly Server
│
├── Filesystem
├── Git
├── Notion
├── Terraform
└── Deployment
This separation is important.
The AI client doesn't directly receive unrestricted access to every system available on the machine. Instead, capabilities are exposed deliberately through individual tools, with defined inputs and, where necessary, explicit confirmation requirements.
For example, the Notion integration exposes separate tools for searching, reading, creating, updating, and deleting resources. Higher-risk operations can require confirm: true before the operation is allowed to proceed.
That gives us a useful boundary: The model decides what it wants to do. The environment determines what it is actually allowed to do.
The execution loop
Once these capabilities are connected, an AI agent can participate in a larger execution loop rather than simply generating code.
The broader workflow looks like this:
The diagram represents the execution model enabled by these capabilities. Not every path in the diagram was exercised in this experiment.
What we did observe is the core mechanism: Claude can request a capability through MCP, Causly Server receives that request, performs the corresponding operation through its tool implementation, and returns the result to Claude.
That creates the foundation for a feedback loop: intent → tool call → execution → result → next action.
This is the important shift.
The AI isn't limited to producing an answer and stopping there. With an execution environment, its output can become an action, that action can produce a new result, and that result can influence what the agent does next.
MCP Turns Capabilities Into Tools
Causly Server uses the Model Context Protocol to expose individual capabilities to an AI client.
For example, the Notion integration registers tools such as:
server.registerTool(
"notion_search",
{
description: "Search pages and databases across the workspace.",
inputSchema: {
query: z.string().optional(),
filter_type: z.string().optional(),
page_size: z.number().optional()
}
},
wrap("notion_search", notionOps.notionSearch)
);
This is more than an API wrapper.
The tool definition tells the AI client:
- what capability exists,
- what inputs it accepts,
- and how the operation is structured.
A write operation can also carry an explicit safety boundary.
For example:
server.registerTool(
"notion_update_page",
{
description:
"Update an existing page's properties. HIGH risk — requires confirm: true.",
inputSchema: {
page_id: z.string(),
properties: z.record(z.any()).optional(),
confirm: z.boolean().optional()
}
},
wrap("notion_update_page", notionOps.notionUpdatePage)
);
The interesting part isn't Notion itself. It's the pattern.
The agent receives a defined capability instead of unrestricted access.
That becomes increasingly important as an AI agent moves from reading information to modifying real systems.
What Happens Behind the Tool?
The registered tool eventually calls an implementation.
The actual Notion search implementation is simple:
export async function notionSearch({
query,
filter_type,
page_size = 20
}) {
const body = { page_size };
if (query) body.query = query;
if (filter_type) {
body.filter = {
property: "object",
value: filter_type
};
}
const data = await notionFetch(
"/search",
{
method: "POST",
body
}
);
return {
results: data.results.map((r) => ({
id: r.id,
object: r.object,
url: r.url,
title:
r.properties?.title?.title?.[0]?.plain_text ||
r.properties?.Name?.title?.[0]?.plain_text ||
r.title?.[0]?.plain_text ||
null
})),
has_more: data.has_more,
next_cursor: data.next_cursor
};
}
The flow is therefore:
Claude
│
│ notion_search(...)
▼
Causly Server
│
│ notionSearch()
▼
Notion API
│
▼
Structured result
│
▼
Claude
The AI can now use the result as context for its next action. This is one of the fundamental properties of an AI agent environment: actions produce new information, and that information influences subsequent actions.
From Tools to Infrastructure
One tool by itself isn't an environment. The difference appears when multiple capabilities can participate in one workflow.
Consider a development task.
An agent may need to:
- inspect an existing project,
- modify files,
- run validation,
- commit changes,
- interact with infrastructure,
- deploy the result,
- verify that the application is actually running.
The environment connects these operations.
This loop is fundamentally different from asking an LLM:
"Write me a React application."
The second produces text. The first creates a system in which the AI can act, observe, and continue.
A Real Permission Boundary
During the local experiment, Claude also interacted with Terraform through the Causly Server MCP layer. The permission prompt made the boundary between the AI client and the underlying infrastructure operation visible.
In the current setup, Claude can request access to infrastructure-related operations, but those operations don't simply disappear behind the chat interface.
The permission boundary is visible.
That is an important detail for AI agent infrastructure. An environment should not only provide capabilities. It should also make the boundary around those capabilities understandable.
The difference between:
"The AI can use Terraform."
and:
"The AI can request a specific Terraform capability through an MCP tool with an explicit permission boundary." is significant.
The second model is much closer to how agent infrastructure needs to work in real systems.
So, Can AI Agents Build Applications?
They can already participate in much more than code generation.
The Causly Server experiment demonstrates the underlying building blocks:
- AI clients can discover structured tools through MCP.
- Tools can expose real external systems.
- Tool inputs can be explicitly defined.
- Higher-risk operations can require confirmation.
- Tool results can be returned to the agent as structured context.
- Infrastructure operations can become part of the same agent workflow.
But there's an important distinction.
We are not claiming that Causly Server has already autonomously built and shipped a production application from start to finish.
That would require a separate controlled experiment with a defined application task, execution environment, measurements, and reproducible results.
And that's exactly where this research gets interesting.
The Missing Piece: The Environment
The biggest lesson so far isn't that AI models suddenly became better programmers. It's that capability changes when the model gets somewhere to execute its decisions.
Without an environment:
Prompt
↓
Model
↓
Code / Answer
With an environment:
Intent
↓
AI Agent
↓
Tool Call
↓
Execution Environment
↓
Result / Error
↓
AI Agent
↓
Next Action
The second loop is where an AI agent starts looking less like a chatbot and more like an execution system.
That's why concepts such as AI agent infrastructure, AI agent environments, AI agent runtimes, and AI agent servers matter.
The model is only one component. The environment determines what the model can actually do.
What We Learned
This experiment changed the question we should be asking about AI coding agents.
Instead of:
"How good is the model at writing code?"
we should also ask:
"What can the model do when it has a reliable environment in which to execute that code?"
That includes the ability to:
- access project files,
- interact with APIs,
- modify external systems,
- work with infrastructure,
- observe execution results,
- recover from failures,
- and continue the workflow.
The model provides the reasoning.
The environment provides the ability to act.
And that distinction may become one of the most important architectural differences between today's AI coding assistants and tomorrow's autonomous AI agents.
What We're Testing Next
Causly Hosted is currently being developed as the managed environment around this idea.
The next step is therefore not another theoretical demo.
It's a controlled experiment:
Give an AI coding agent a real isolated environment, give it a defined application-building task, and measure what it can actually complete.
That experiment should answer the questions that this first investigation leaves open:
- How much of an application can the agent build without intervention?
- How many execution cycles does it need?
- Where does it fail?
- How often does it recover from failures?
- What infrastructure capabilities are actually necessary?
- Where does human approval remain important?
Those are measurable questions.
And that's where AI agent infrastructure becomes something we can study rather than simply speculate about.
Explore the implementation
The Causly Server project is open source, so the MCP architecture and tool definitions can be inspected directly in the codebase.
GitHub: https://github.com/KNIHAL/causly-server
The point of making the server open source is simple: the infrastructure should be something developers can inspect, experiment with, and build on—not just something described in a product page.