DEV Community: ABP.IO

Deep Dive on ABP AI Agent #9: Workflows

ABP.IO — Fri, 19 Jun 2026 06:39:24 +0000

Deep Dive on ABP AI Agent #9: Workflows

There is a pattern I see in almost every real development session.

The interesting part is the code change, but the repeated part is everything around it:

start the containers,
build the affected packages,
add a migration if the model changed,
regenerate proxies if the API contract changed,
restart the application,
run the validation task,
check the logs when something fails...

When I work alone, I can do those steps manually. When I work with an AI coding agent, I do not want to keep pasting the same checklist into every prompt. I want the tool to understand that this solution has a normal way of preparing, validating, and recovering after changes.

That is the point of ABP Studio AI Agent Workflows.

Workflows let me define repeatable actions around an agent run. The model can focus on the ambiguous part, understanding the requirement and changing the code, while ABP Studio handles the deterministic parts that should happen before or after the work.

That combination is one of the clearest differences between ABP AI Coding Agent and a generic coding assistant. It is not only an editor with a chat panel. It is an agent inside a platform that already knows how to build, run, migrate, generate proxies, manage containers, execute tasks, and inspect runtime signals.

Why Workflows Matter?

LLMs are powerful because they can reason through unclear requirements and modify code across files. But many development steps should not be creative.

If the team always builds a package after an application service change, that should be predictable. If API contract changes require proxy generation, that should not depend on whether I remembered to mention it. If a local run needs containers before the application starts, that setup should not be reinvented in every prompt.

Workflows give ABP Studio a place to encode those repeatable steps.

For me, the value is not only automation. It is also consistency.

Instead of asking:

Please implement this, and then build, and maybe regenerate proxies,
and restart the app, and also add a migration if needed.

I can configure the workflow once and let the agent session carry that context.

That makes the prompt cleaner:

Add the missing status filter to the order list.
Use the selected workflow for validation after the change.

The workflow becomes part of the development environment, not a long instruction I repeat manually.

Before And After The Agent Works

An AI Agent workflow has two sides:

Before steps prepare the environment before the agent starts coding.
After steps guide the validation and follow-up work after the main task is complete.

Before steps run automatically in Agent mode. They are useful for setup actions that should happen before the model receives control, such as starting containers or running a preparation task.

Plan and Ask modes are read-only, so they do not execute before steps. That separation is important. If I am only asking a question or asking for a plan, I do not want Studio to start applications or run mutation-oriented tooling.

After steps are injected into the agent instructions as post-task guidance. The agent is expected to run the relevant post-steps after completing the work, but it can skip actions that do not apply.

For example, if my workflow includes "Add Migration" but the change does not touch the EF Core model, the agent should not create an empty migration just because the workflow exists. The workflow gives deterministic options, but the agent still uses the actual change to decide what is relevant.

What A Workflow Can Do?

Workflow actions are built around the things ABP developers already do in ABP Studio.

The supported actions include:

Build the solution, selected modules, selected packages, or configured targets.
Start Application for selected applications, folders, or all runnable applications.
Stop Application when validation needs a clean state.
Restart Application after code changes.
Start Containers for databases, caches, message brokers, or other dependencies.
Stop Containers when the workflow needs to clean up.
Run Task for configured ABP Studio tasks.
Add Migration when entity changes require a database migration.
Generate C# Proxies after contract changes.
Generate Angular Proxies after API changes consumed by Angular clients.

That list is very ABP-specific.

A generic coding tool can run shell commands, and that is useful. But ABP Studio workflows know about ABP Studio concepts: applications, containers, run profile tasks, packages, modules, migrations, and proxy generation. The agent can use those as first-class actions instead of trying to infer everything from terminal commands.

Personal And Shared Workflows

Workflows can be personal or shared.

A personal workflow is stored locally under the solution workspace. It is useful for my own development habits. Maybe I like restarting a specific app after each agent turn. Maybe I have a local task that only makes sense on my machine.
A shared workflow is stored with the active run profile. That makes it suitable for source control and team usage.

This is where workflows become more than a convenience feature. A team can encode its normal AI-agent validation path into the solution itself.

For example:

Before:
- Start required containers
- Run the prepare-local-environment task

After:
- Build affected packages
- Generate Angular proxies when contracts changed
- Restart the Web and API applications
- Run the smoke-test task

Every developer using that run profile can work with the same repeatable loop. The workflow does not replace code review or testing, but it raises the baseline for what happens after the agent touches code.

Workflows Make AI More Deterministic Where It Should Be

I do not want the model to creatively decide whether my team usually runs proxy generation. I want the workflow to encode that.
I do not want every prompt to include a long validation checklist. I want the workflow to carry it.
I do not want an agent to guess which applications belong to the local run. I want ABP Studio's run profile to provide that context.

This is why workflows are such a strong fit for ABP Studio AI Coding Agent. The model stays flexible where flexibility helps, and the platform stays deterministic where determinism matters.

The result is a cleaner division of responsibility:

| Responsibility | Best handled by | | --- | --- | | Understanding the requirement | AI Agent | | Finding and editing relevant code | AI Agent | | Starting known containers | Workflow | | Running known tasks | Workflow | | Adding migrations when needed | Agent using workflow action | | Generating proxies when contracts change | Agent using workflow action | | Building affected packages | Workflow / Studio tools | | Investigating runtime failures | Agent using monitoring tools |

Workflows And Scopes Together

Workflows are even better when combined with AI Scopes.

Scopes define where the agent can work. Workflows define what repeatable actions should happen around that work.

For example, I can select a Catalog scope and a workflow that:

builds the Catalog package,
regenerates proxies if contracts changed,
restarts the public web app,
checks recent exceptions after restart.

That is a focused agent loop. The agent does not need the whole repository, and the validation path does not need to be invented from scratch.

This is the kind of full flow that makes ABP AI Coding Agent feel different from tools that only operate at the file-and-terminal level.

Why This Is Different From Generic Coding Agents

Generic coding agents can be excellent: Cursor, Claude Code, Codex, Windsurf, and similar tools can read code, edit files, run shell commands, and help across many kinds of projects.

But ABP Studio AI Coding Agent is built for a different experience: It works inside ABP Studio, where the solution already has run profiles, applications, containers, tasks, modules, packages, migrations, proxy generation, monitoring, Git integration, and ABP-aware analysis.

Workflows use that platform context.

Instead of saying:

Run whatever commands seem appropriate.

I can say:

Use the selected ABP Studio workflow.

That is a very different contract. The workflow is visible, configurable, repeatable, and tied to the solution.

For ABP teams, this matters because the development process is not only code generation. It is code generation plus build, migration, proxy generation, application restart, runtime observation, and review.

ABP Studio AI Coding Agent is designed for that full loop.

Conclusion

Workflows make ABP Studio AI Coding Agent more practical for real development.

They let me move repeated setup and validation steps out of my prompt and into the platform:

start what needs to be running,
build what needs to be built,
generate what needs to be regenerated,
migrate when a model change requires it,
restart the relevant apps,
and continue the debugging loop with runtime evidence.

That is why I see workflows as one of the features that makes ABP AI Coding Agent feel complete.

The agent is not isolated from the development environment. It works inside ABP Studio, with the same solution structure, run profile, tools, and team workflow that I already use.

That is the difference: not just AI-generated code, but an AI-assisted ABP development flow from change to validation.

Deep Dive on ABP AI Agent #8: Parallel Agent Execution

ABP.IO — Thu, 18 Jun 2026 06:14:13 +0000

Deep Dive on ABP AI Agent #8: Parallel Agent Execution

Real work rarely lines up one task at a time.

While the agent is busy adding a feature, a question comes up about a different module. A review is waiting. A small fix would take two minutes, but the agent is in the middle of something else. With a single session, you wait. You watch one task finish before you can start the next, even when the two have nothing to do with each other.

ABP Studio does not make you wait. It can run several agent sessions at the same time, each on its own task.

Parallel Agent Sessions

A session is one conversation with the agent. It has its own history, its own mode, its own model, its own scope, and its own workflow. ABP Studio keeps multiple sessions per solution, and they can run in parallel.

There is a limit, and it is there on purpose. By default you can run up to 3 sessions at once , and you can set that anywhere from 1 to 5. When you send more prompts than there are open slots, the extra ones are queued and start as soon as a slot frees up.

So "parallel" here is not a trick of switching back and forth quickly. The sessions actually run at the same time, up to the limit you choose.

Parallel Session Use Cases

The point is to stop letting one task block another. A few ways it plays out:

One session implements a feature while another answers questions about a different part of the solution.
Two unrelated modules get worked on at once, each in its own session.
One session writes the code while another reviews a diff or does research.

Because each session is separate, you can even point them at different parts of the solution and give them different jobs:

Session 1 (Agent): Add a Category screen to the Catalog module.
Session 2 (Ask): Explain how permissions flow from the API to the UI.

The first one edits files. The second one only reads and answers. They do not interfere, because they are different sessions with different settings.

Per-Session Settings Isolation

This is the part that makes parallel work predictable instead of chaotic.

When a session sends its first message, two things happen at different levels. The session permanently locks its scope and workflow —these stay fixed for the entire session lifetime and cannot be changed once the first message is sent. On the other hand, the model , mode , and active tools are snapshotted fresh at each run (each turn the agent takes), so they reflect whatever is configured at the moment the run starts but remain stable for its duration.

That matters the moment you have more than one session open. Say one session is running in the background, scoped to the Catalog module. You switch the foreground to a different scope to start a second task. The background session does not notice. It keeps the scope and workflow it was locked to, and each of its runs uses whatever model and tools were configured at the moment that run began.

Without this, parallel sessions would quietly corrupt each other every time you changed a setting. With it, each session is a sealed unit of work.

The Prompt Queue

You do not have to wait for a session to be idle to line up its next step.

While a session is running, you can queue more prompts on it. They attach to the same session and are sent one after another, each after the current turn finishes. The queue keeps the session's settings, so a queued prompt runs with the same mode, scope, model, workflow, and active plan as the rest of that session.

This works together with the concurrency limit. Prompts that cannot start right away, because every slot is busy, simply wait their turn instead of failing.

Keeping Parallel Work Safe

Running several sessions at once is powerful, and it also gives you a new way to get in your own way: two sessions editing the same files.

ABP Studio helps here, but it does not pretend the problem away. It tracks file changes, so if one session edited a file after another session read it, the second is told to read it again before overwriting. It also serializes operations that cannot safely overlap, such as adding a migration while a build is running, so two sessions do not run conflicting dotnet commands at the same time. And because each session tracks its own pending questions, one session waiting on your input does not freeze the others.

Still, the simplest rule is the best one: keep parallel Agent-mode sessions on separate parts of the solution. This is exactly where scopes earn their place. Give each session its own scope, and they stay in their own lanes by design instead of by luck.

A Second Kind Of Parallel: Subagents

There is also a smaller, quieter form of parallel work that happens inside a single session.

When the agent needs to look something up, it can fan out multiple subagents in a single turn: read-only helpers that research in parallel and return their results before the main agent continues. There are a few kinds, each with a narrow job:

one that researches your solution and code,
one that searches the web,
one that searches and reads the official ABP documentation.

These research-style subagents (code research, web search, documentation search) are read-only—they cannot modify files or solution state. They only read, gather, and hand back a short summary. That keeps the main session's context clean, because the digging happens elsewhere and only the answer comes back. (Note that the browser subagent is an exception: it is stateful and can mutate the shared browser session.)

ABP Studio can use a separate model for research subagents, configured apart from your main one. A fast, cheap model is the right choice for this kind of lookup work.

So there are two scales of parallel here. Sessions run independent tasks side by side. Subagents run read-only research inside one task. Both keep the slow parts from blocking the useful parts.

ABP Studio Parallel Execution Model

Plenty of tools let you open more than one chat, and that is genuinely useful. So the idea of running agents in parallel is not, by itself, an ABP feature.

The difference is that each session here carries the context of an ABP solution and stays inside it. A session locks its scope and workflow permanently, and snapshots its model and tools per run, so background work does not drift when you change the foreground. Studio coordinates the operations that would otherwise collide, like builds and migrations, across all the running sessions. And scopes give each session a clear boundary, so parallel does not turn into a pile of agents editing the same files.

In short, the parallelism is not just several chat windows. It is several controlled, solution-aware sessions that know how to stay out of each other's way.

Conclusion

Parallel execution is about respecting how work actually arrives: more than one thing at a time, often unrelated.

ABP Studio lets you run several agent sessions together, each sealed to its own settings, with a queue for what comes next and guardrails for the places where parallel work could collide. Inside each session, subagents add a second layer of parallel research without cluttering the main task.

Deep Dive on ABP AI Agent #7: Scopes

ABP.IO — Wed, 17 Jun 2026 06:35:09 +0000

Deep Dive on ABP AI Agent #7: Scopes

When I use an AI coding agent in a real ABP solution, I do not always want it to see everything.

That may sound strange at first. More context usually feels better. But in a large solution, more context can also mean more noise, more unrelated files, and more chances for the agent to drift into an area that is not part of the task.

If I am working on the public side of a modular application, I do not want the agent to redesign the admin side. If I am changing a Catalog module, I do not want it to spend half the session reasoning about Identity, SaaS, or Payment code. If I am fixing one microservice, I do not want the agent to treat the whole platform as editable surface area.

That is where AI Scopes become one of the most important control features in ABP Studio AI Coding Agent.

Why Scopes Matter?

Most AI coding agents are very good at reading a folder and making changes. That is useful, but an ABP solution is rarely just a folder.

An ABP solution can contain modules, packages, applications, gateways, background workers, database projects, shared contracts, UI projects, and infrastructure configuration. In a microservice solution, the repository may contain multiple independently meaningful services. In a modular monolith, a single solution may still have clear business boundaries.

-> In those situations, the question is not only: Can the agent understand the solution? ❌

-> The better question is: Which part of the solution should the agent be allowed to work with for this task? ✅

AI Scopes answer that question directly.

They let me choose the accessible area before the session starts. The agent can then focus on the relevant module, package, solution area, or external folder instead of treating the entire repository as equally relevant.

For me, that changes the feeling of using an AI agent. It is no longer "here is my whole codebase, please be careful." It becomes "here is the part of the system this task belongs to, work inside that boundary."

What An AI Scope Controls?

An AI Scope restricts which directories the agent can access during a session.

Depending on the task, a scope can include:

the whole solution,
selected modules,
selected packages,
selected external folders,
or a focused combination of these.

The important part is that this is not only a prompt suggestion. It is part of the session context and file access boundary. File paths used by the agent are validated against the resolved scope. If a file is outside the accessible directories, the agent should not treat it as part of the editable workspace.

Scopes also work together with .abpignore. Even if a file is under an accessible directory, files excluded by .abpignore remain blocked. That gives teams two useful layers:

Scopes decide which solution areas are relevant to the task.
.abpignore protects files that should stay inaccessible, such as secrets, certificates, environment files, or other sensitive local data.

This is a practical control model. I can narrow the agent's working area without pretending that the repository is smaller than it really is.

Scope Is Locked To The Session

Another detail I like is that scope belongs to the AI Agent session.

The first message of a session locks the configuration that affects the system prompt, including the active AI Scope. If a background session continues running and I change the foreground scope later, that running session does not silently change its context.

That matters when multiple sessions are active.

Imagine I have one session working on a Catalog module and another session answering questions about the whole solution. Those sessions should not accidentally share a changing boundary. Each one should keep the scope it started with.

This makes scopes more predictable. I can choose the scope intentionally at the beginning of the work and trust that the session is tied to that decision.

Focused Autonomy

Scopes are not about making the agent weaker. They are about making autonomy more focused.

When I narrow the scope, I am not saying the agent is less capable. I am saying the task has a boundary.

For example:

Use the Public AI Scope.
Add a small validation improvement to the public product search flow.
Do not inspect or change the Admin side unless you find a direct contract dependency.

That kind of prompt becomes much stronger when the selected scope already matches the instruction. The agent receives both the natural-language task and the platform-level boundary.

This is especially useful for ABP because ABP applications are built around clear concepts: modules, layers, packages, application services, repositories, DTOs, permissions, localization resources, DbContexts, and run profiles. A scope can follow those boundaries instead of relying only on a long prompt.

What Scopes Help Prevent?

Scopes help reduce a few common AI-agent failure modes.

First, they reduce unrelated exploration. The agent does not need to spend time discovering files that have nothing to do with the task.
Second, they reduce accidental edits. When a task belongs to one module, the agent should not casually change another module just because it found a similar type there.
Third, they improve reviewability. If I scoped the task to Catalog, and the diff changes Identity, that is immediately suspicious. The boundary makes the review easier.
Fourth, they support parallel work. Different sessions can be scoped to different areas, which is useful when independent tasks are running in the same solution.

This is one of the places where ABP AI Coding Agent feels different from a generic coding tool. The feature is not only "the model can read fewer files." It is integrated into ABP Studio's understanding of the solution.

Scopes And ABP Solution Architecture

ABP already encourages clear boundaries.

In a layered module, the Domain layer should not depend on the Application layer. HTTP API projects should depend on contracts, not implementation projects. Entity Framework Core and MongoDB integrations should stay behind the domain abstractions. A reusable module should be understandable as a module, not only as a set of files.

AI Scopes fit naturally into that mindset.

If I am working on a Domain change, I can keep the scope close to the module and its required shared contracts. If I am working on UI behavior, I can include the UI package and the related contract package. If I am working on a microservice, I can scope the agent to that service and only add external folders when they are truly required.

That means the agent's working area can follow the same mental model I already use as an ABP developer:

What bounded area owns this change?
Which packages are needed to make it safely?
Which parts of the system should stay out of this session?

Scopes And Workflows Work Better Together

Scopes define where the agent can work.
Workflows define what deterministic actions should happen around that work.

That combination is powerful. For example, I can scope the agent to the Catalog module and use a workflow that builds the affected package, regenerates proxies if contracts changed, and restarts the related application.

The scope keeps the coding session focused. The workflow keeps the verification loop repeatable.

This is the larger ABP Studio AI story. It is not only an AI chat window. It is an agent inside a platform that already understands ABP solutions, run profiles, tools, workflows, Git state, and runtime signals.

Why This Is Different From Generic Coding Agents?

Tools like Cursor, Claude Code, Codex, and Windsurf are strong general-purpose coding tools. They can read files, edit code, run shell commands, and help with many projects.

ABP AI Coding Agent is different because it is built around ABP Studio's view of an ABP solution.

Scopes are a good example of that difference.

In a generic tool, I can try to simulate scope with a prompt:

Only work in this folder.

That is helpful, but it is still mostly an instruction. In ABP Studio, scope is part of the agent session and file access model. It can be selected intentionally before the work starts, stored with the session, and combined with .abpignore, workflows, tools, plans, and run profile context.

For professional ABP teams, that matters. The goal is not to give an AI agent unlimited access and hope the prompt is clear enough. The goal is to create a controlled development loop where the agent understands the system, works in the right area, uses the right tools, and produces a diff that is easier to trust.

Conclusion

AI Scopes make ABP Studio AI Coding Agent feel more deliberate.

They let me say:

this is the part of the solution that matters,
this is the boundary for the current session,
this is the context the agent should focus on,
and everything else should stay outside unless we intentionally expand the scope.

That is exactly the kind of control I want when using AI in real ABP solutions.

The agent can still be powerful. It can still plan, edit, build, run tools, and iterate. But with scopes, that power is pointed at the right part of the system.

That is the real value: not just more AI autonomy, but better-shaped AI autonomy for ABP development.

Deep Dive on ABP AI Agent #6: ABP Studio Git Integration

ABP.IO — Tue, 16 Jun 2026 09:25:54 +0000

Deep Dive on ABP AI Agent #6: ABP Studio Git Integration

When I use an AI coding agent, I do not only care about whether it can change files.

I care about what happens around those changes.

Which branch am I on? What exactly changed? Can I review the diff before I commit? Did I accidentally touch a file from another package? Is my branch behind the default branch? If a pull request already has feedback, can I bring that context back into the coding session without copying every comment by hand?

That is where Git integration in ABP Studio becomes important.

Git is not just the final step after the agent finishes. For me, it is the confidence layer around the whole workflow. It helps me keep AI-assisted work reviewable, recoverable, and connected to the same team process I already use every day.

Git In The AI Workflow

Most development work is not a straight line from prompt to done.

I may ask ABP Agent to make a small change, then review the diff and adjust the direction. I may ask it to address feedback from a pull request. I may start from a GitHub issue, create a branch, let the agent investigate, and then decide which changes are ready to commit.

In all of those moments, Git gives me a practical boundary:

this is the branch I am working on,
these are the files that changed,
this is the diff I need to review,
this is the commit I am about to create,
and this is the context I want to send back to the team.

Without a Git-aware workflow, AI changes can feel a little too loose. The agent may be productive, but I still need a clean way to inspect, group, commit, push, and discuss the result.

ABP Studio Git Integration brings that loop into the same place where I already work with the solution and the agent.

Initializing Git For A Solution

The Git panel starts with the active solution.

If the solution is not a Git repository yet, ABP Studio does not pretend otherwise. It shows a simple empty state and lets me initialize Git from there. I can choose the initial branch name, create a .gitignore, and create the first commit.

That is useful for new ABP solutions because the first Git step is part of the project setup, not something I need to remember after the fact.

If I want to put the solution on GitHub, Studio can also help with that path. After connecting my GitHub account, I can publish the repository under my account or an organization, choose the repository name, add a description, and decide whether it should be private.

The small but important detail is that Git becomes part of the solution experience early. I do not need to move from ABP Studio to a separate Git tool just to create the repository before I start working with ABP Agent.

Changed Files And Diff Review

Once Git is active, the Git panel becomes the place I check after an agent session or a manual edit.

I can see the current branch, remote state, changed files, and the selected file diff. The changes are not only a flat list. In an ABP solution, they can be grouped in a way that follows the solution structure, so changes under different packages or solution areas are easier to scan.

That grouping matters in real ABP work.

If I asked ABP Agent to adjust a public web page, but I see changes in an admin package, I immediately know to slow down and review why. If a change touches a contract package and a UI package, the grouping helps me understand that relationship before I commit.

The diff viewer is also part of the same loop. I do not need to leave the workspace just to answer the basic review question:

What did this task actually change?

That is the question I want to answer before a commit, especially when AI helped produce the diff.

Selected Files And Commit Messages

Committing is not only pressing a button.

I still want to choose which files belong together. I still want the commit message to match the change. I still want to avoid committing work on a protected branch by accident.

ABP Studio keeps that flow visible. I can select the files I want, write a summary and description, and commit to the current branch. When AI is enabled, Studio can generate a commit message from the selected diffs.

I like this because it keeps the AI help close to the actual diff.

A generic prompt like "write a commit message" depends on what I paste into the chat. In Studio, the commit message generator can work from the selected files. That makes the result more focused, and I still stay in control because the generated text lands in the commit fields before I use it.

The protected branch warning is another important part of the experience. If the current branch should not receive direct commits, Studio makes that visible and pushes me toward the safer workflow: create a branch, review the diff, then commit there.

That is the right kind of guardrail. It does not make Git complicated. It makes the normal team habit harder to miss.

Branching, Stashing, And Syncing

AI-assisted development often starts with a branch decision.

Sometimes I am starting fresh from the default branch. Sometimes I am building on work already in my current branch. Sometimes I have local changes and need to switch context without losing them.

ABP Studio exposes those decisions in the Git panel.

I can create a branch, switch branches, update from the default branch, fetch, pull, push, and see whether I am ahead or behind. If I switch branches while I have local changes, Studio asks what should happen to that work: leave it behind as a stash or bring it with me.

That choice is more important than it looks.

When I am working with an agent, I do not want local changes to silently follow me into the wrong branch. I also do not want to lose half-finished work just because I need to inspect another issue. The stash flow turns that into an explicit decision.

The same idea applies to sync.

If my branch is behind, I can update before I continue. If I have local commits, I can push them. If a merge or pull produces conflicts, Studio shows the conflicted files and gives me a path to resolve, abort, continue, or send the conflict context to ABP Agent.

That keeps the Git workflow close to the coding workflow. I can move from change to review to sync without mentally switching tools.

AI Review And Manual Diff Comments

There is a moment before a commit where I often want a second look.

Not a full pull request review. Not a long architecture discussion. Just a focused pass over the files I selected:

Does this diff contain something suspicious?
Did the agent miss a small edge case?
Is there a line I should check again before committing?

ABP Studio supports that with AI review on selected Git changes.

AI review is not the only way to leave notes on a diff. I can also write my own comments directly on changed lines while I am reviewing.

The useful part is that the review is attached to the diff. Suggestions and notes appear near the changed lines, and if there is something I want the agent to handle, I can send those review notes to ABP Agent.

That changes the feel of the workflow.

Instead of asking the agent to code and then manually re-explaining my review comments, I can turn the review result back into a task. Whether a note comes from AI review or from something I wrote myself, the agent gets the file, line, and note context. I still review the result, but I spend less time copying context between places.

Git also helps with recovery. In a Git repository, ABP Studio can offer Back to this point in the agent conversation. For me, that is a comfort feature: if an agent turn takes the work in the wrong direction, I can return to an earlier point instead of manually untangling every changed file.

I still treat Git commits as the real checkpoints for team work. But during a live agent session, being able to go back to a previous point makes experimentation feel less risky.

GitHub Issue Context

Many tasks do not start as a prompt. They start as an issue.

The issue has the requirement, comments, labels, screenshots, and sometimes a conversation about what is expected. If that context stays only in the browser, I have to copy it into the agent manually.

ABP Studio can bring GitHub issues into the Git area.

I can filter issues, open one, read the description and comments, create a branch for that issue, and send the issue context to ABP Agent.

That makes the workflow feel natural:

Pick the issue.
Create a branch for it.
Send the relevant context to ABP Agent.
Let the agent inspect the solution and implement the change.
Review the Git diff before committing.

The important detail is that the agent starts from the same context I would start from as a developer. It sees the issue title, description, labels, included comments, and attached images when they are part of the selected context.

That is much better than writing a vague prompt that tries to summarize the issue from memory.

Pull Request Feedback Context

Pull request feedback is another place where Git integration helps the AI workflow.

When I open a pull request inside ABP Studio, I can see the PR title, branches, comments, reviews, and requested changes. If I am not on the PR branch, Studio can switch to it. Then I can choose which comments or requested changes should be included and send that context to ABP Agent.

This is the workflow I want when a reviewer asks for changes:

read the feedback,
switch to the right branch,
include only the relevant comments,
send the request to ABP Agent,
review the resulting diff,
commit and push.

The include and exclude controls matter here. Not every PR comment should become an agent instruction. Some comments are discussion, some are already resolved, and some are optional. I want to choose what becomes context.

That keeps the agent from treating the entire PR timeline as one undifferentiated command. I can shape the task before sending it.

Git Integration In The Deep Dive Series

In the earlier articles, we looked at modes, tools, MCP, scopes, and workflows.

Git integration connects those ideas to the normal development lifecycle.

Ask and Plan help me understand and shape the work.
Agent mode can make the change.
Tools help the agent use ABP Studio context.
Scopes keep the working area focused.
Workflows make repeated actions predictable.
Git integration lets me review, recover, commit, push, and collaborate around the result.

That last part is easy to underestimate.

The value of an AI coding agent is not only how quickly it can modify files. The value is whether I can bring those modifications into a professional development workflow without losing control.

Git is the structure that makes that possible.

Conclusion

ABP Studio Git Integration makes ABP Agent feel more grounded.

It gives me a clear path from issue to branch, from agent work to diff review, from selected files to commit, and from pull request feedback back into the agent.

For everyday work, that means fewer context switches. For AI-assisted work, it means more confidence.

I can let the agent help, but I do not have to accept the result blindly. I can inspect the diff, ask for a review, commit intentionally, push when ready, and keep the whole process connected to GitHub and the team workflow.

That is the part I value most: Git integration turns AI output into reviewable development work.

Deep Dive on ABP AI Agent #5: MCP (Model Context Protocol)

ABP.IO — Mon, 15 Jun 2026 06:06:24 +0000

Deep Dive on ABP AI Agent #5: MCP (Model Context Protocol)

When I use an AI coding agent inside ABP Studio, most of the work starts inside the solution.

The agent can read the code. It can edit files. It can use the ABP Studio tools I enabled. It can build the solution, run tasks, start applications, inspect containers, and check monitoring data when something fails. In the previous article of this series, we focused on exactly that: the integrated tools that connect the agent to the ABP Studio development environment.

But there is another point where plain solution awareness is not enough.

Sometimes the information I need is not in the repository. It is not in the running application. It is not in the build output, container state, or ABP Studio monitoring screen.

It may be in a live Prometheus workspace. It may be in Google Search Console. It may be in an SEO analyzer, a documentation system, a database, a customer support tool, or another service that has nothing to do with the ABP solution itself.

That is where MCP becomes useful.

MCP, short for Model Context Protocol , gives ABP AI Coding Agent a standard way to reach external tools and data sources. It does not replace the built-in ABP Studio tools. It extends the agent beyond the solution boundary when the task depends on something outside that boundary.

Note: ABP AI Coding Agent is available directly to ABP license holders. License holders have predefined credits so they can try the integrated experience without setting up a separate AI workflow first. MCP is one of the ways this experience can be extended when the agent needs access to systems outside ABP Studio.

Why MCP Matters

Most coding agents start from the same place: the files they can see.

That is a good start, but real development work often needs context from somewhere else: production metrics, SEO data, analytics, search performance, customer records, internal APIs, or product knowledge.

If the agent cannot reach those systems, the developer becomes the bridge:

Copy this metric result.
Paste that SEO report.
Export this analytics data.
Summarize this dashboard.
Explain which production signal matters.
Tell the agent what the external system says.

That works, but it is not the best workflow. The more information I manually copy into the chat, the easier it is to miss something, simplify too much, or give the agent an outdated snapshot.

MCP reduces that manual work. It lets the agent ask an external system for context directly, within the permission boundary I configure.

The important detail is that MCP is not "the agent can do anything now." It is a controlled extension point. A server is connected. Its tools are listed. Individual tools can be enabled or disabled. The agent can only use what is available in the current session.

That gives me a practical balance: the ABP-aware development experience stays in ABP Studio, and external context can be added only when the task needs it.

What MCP Actually Is

MCP is an open standard for connecting external tools and data to AI agents.

Instead of every tool inventing its own integration for every agent, MCP defines a common shape. A program that exposes tools or resources through this standard is called an MCP server. An agent that understands MCP can connect to that server and use what it provides.

For me, the easiest way to think about it is simple:

ABP Studio tools connect the agent to the ABP development environment.
MCP servers connect the agent to systems outside that environment.

The server might expose a tool for querying Prometheus, checking Search Console data, running an SEO audit, inspecting a database, or calling an internal API. The exact capability depends on the server.

MCP is not a prompt, a rule, a skill, or a lesson. Those shape what the agent knows or how it behaves. MCP changes what the agent can reach.

That makes MCP more like equipment than instruction. It gives the agent access to a tool or data source that was previously outside its working area.

There are already many community and vendor MCP servers for different systems. A useful place to discover examples is the awesome-mcp-servers repository, which collects MCP servers across many categories.

For concrete examples, there are MCP servers for Prometheus metrics, AWS Managed Prometheus, and SEO analysis. The exact server you choose depends on your environment, but the pattern is the same: expose a focused external capability to the agent through MCP.

When You Actually Need It

Most of the time, I would not start with MCP.

For normal ABP development, the built-in tools are usually the right first layer. The agent can already work with the solution, run profiles, applications, containers, tasks, builds, monitoring data, and documentation. If the task is completely inside the ABP solution, MCP may not add anything.

MCP becomes useful when the task crosses the solution boundary.

For example, I may ask:

Run an SEO audit for https://abp.io, summarize the weak areas, and suggest which content or technical improvements would matter most.

Without MCP, I would need to open a separate SEO tool, run the audit, copy the results, and paste them into the chat. With the right MCP server enabled, the agent can call the SEO tool directly and reason from the structured result.

Or I may ask:

Connect to our Prometheus MCP server, check the error rate and p95 latency for the AuthServer over the last 30 minutes, and tell me whether the last deployment changed anything.

That is a very different kind of task. The answer is not in the source code alone. It lives in a monitoring system. Prometheus MCP servers exist for this kind of workflow; for example, some expose tools for instant PromQL queries, range queries, metric discovery, and target inspection.

Another realistic prompt could be:

Use Search Console data to find pages that lost traffic this month, then inspect the related docs pages and suggest focused improvements.

Again, the important part is not that the agent magically knows everything. The important part is that I can connect a specific external system, expose a specific set of tools, and let the agent use them when they are relevant.

If the work starts outside the codebase but ends inside the codebase, MCP can help connect those two parts of the workflow.

Setting Up An MCP Server

MCP servers are configured under Settings > MCP Servers.

When no server is connected, the page is intentionally simple. It is an empty list waiting for the first server. That is important because MCP should be explicit. If I have not connected a server, the agent should not behave as if it has access to that external system.

When I add a server, ABP Studio asks how it should connect.

There are two main connection types:

Stdio: ABP Studio runs the MCP server as a local process. I provide the command, arguments, and environment variables the server needs.
HTTP: ABP Studio connects to an MCP server over the network. I provide the URL and any required headers.

This is useful because different MCP servers are packaged in different ways. Some are local command-line programs. Some are hosted services. Some need environment variables for tokens or configuration.

In the example below, I am adding an HTTP MCP server named SEO Analyzer. It exposes a small set of SEO-related tools through a remote MCP endpoint.

ABP Studio does not require every server to be created manually from scratch. If I already use MCP elsewhere, I can import existing configuration from tools like Cursor, Claude, VS Code, Windsurf, or a plain MCP server JSON file. It can also export configuration in the standard mcpServers JSON shape.

That matters because MCP is an open ecosystem. The same server definition can often move between tools. ABP Studio becomes another place where I can use that server, but now in the context of an ABP-aware agent.

What A Connected Server Shows

After a server is connected, ABP Studio shows the important parts of the connection.

I can see whether the server is connected, how many tools it exposes, which tools are available, and whether it provides resources. I can also inspect resources directly from the settings page.

This visibility matters because an MCP server is not just a checkbox. It is a surface area. It may expose one tool or many. Some tools may be read-only, and some may perform actions outside the repository.

The agent does not need me to call those tools manually. I describe the task, and if the tool is available and relevant, the agent can decide to use it. That is why a prompt can stay natural:

Read the product requirement from the connected knowledge base and compare it with the current implementation.

The prompt does not need to become a tool invocation script. The agent still owns the reasoning loop. MCP only gives it a new place to look.

Tool Access: What The Agent Is Allowed To Use

The most important part of MCP in ABP Studio is not only connecting servers. It is controlling what the agent is allowed to use.

Individual tools can be disabled. If a tool is disabled, it is not offered to the agent. The agent should not plan around it, call it, or assume it has access to it.

That is useful for safety, but also for quality.

Every enabled tool becomes part of the menu the agent considers. If a server exposes ten tools but the current task only needs two, I usually prefer to enable only those two. A shorter tool list is easier for the agent to choose from. It also makes the session easier for me to reason about.

The permission model is simple:

If a server is not connected, the agent cannot use it.
If a server is disabled, the agent cannot use its tools.
If an individual tool is disabled, the agent cannot use that tool.
If the session is not in Agent mode, MCP tools are not available.

That last point is important. MCP tools are available in Agent mode only.

Plan and Ask modes are read-only by design. They are useful for understanding, planning, and discussing changes, but they do not receive MCP tools. If I want the agent to call an external MCP tool, I need to work in Agent mode.

This keeps the model consistent with the rest of the ABP AI Coding Agent experience. The mode determines what kind of work the agent is allowed to perform.

Keeping MCP Safe

MCP is powerful because it lets an AI agent reach systems outside the solution.

That is also why it needs care.

An MCP server is a program. It may read files, call APIs, query databases, send requests, or perform actions depending on how it was built. The agent is not inventing those capabilities. It is using what the server exposes.

So trust matters at two levels.

First, I need to trust the actions. If a tool can update an issue, send a message, change a record, or trigger a workflow, that is a real side effect.

Second, I need to trust the descriptions. When an MCP server connects, the names and descriptions of its tools become part of what the model can read. A careless or hostile server can use that text to influence the model before I even write my prompt.

That means MCP safety is not only about "what can this tool do?" It is also about "what instructions or descriptions does this server place in front of the model?"

Two habits keep this manageable:

Connect only servers I trust.
Disable tools the agent should not use for the current task.

This sits on top of the agent's normal guardrails. Shell commands, URL fetches, downloads, and other sensitive actions can still require permission. Also, the tool list is fixed for a running session, so changing a server in the middle of a session does not quietly alter the tool surface already given to that session.

That is the behavior I want from this kind of integration. MCP can extend the agent, but it should do so through visible, intentional configuration.

A Practical MCP Walkthrough

Let me make this more concrete with a small scenario.

Imagine I am working on the public website or documentation side of an ABP-based product. The task is not a compiler error or a failing unit test. I want to understand how the website looks from an SEO perspective and what I would improve first.

Without MCP, I would open a separate SEO tool, run the audit, wait for the result, copy the score, paste the table into the chat, and then ask the agent to interpret it. That is not terrible, but it turns me into a copy-paste integration layer.

With an SEO Analyzer MCP server connected, I can start from a better prompt:

Please rate the SEO work on the https://abp.io website on a scale of 1 to 10. I'd also like to know what you would do if you were in charge.

At that point, the agent can use the SEO Analyzer MCP tool instead of guessing from general SEO knowledge alone. It can call the audit tool, read the structured result, and turn it into a concrete improvement plan.

The value is not only that the agent saved me a few seconds. The value is that the agent starts from live tool output instead of a manually summarized report.

First, Without The MCP Server

If no SEO MCP server is connected, the agent cannot run the audit directly.

It may still give a reasonable answer from general knowledge. It may say that the site should have good titles, descriptions, headings, performance, backlinks, structured data, and content targeting. That advice can be useful, but it is generic.

For example, I might write:

Review the SEO of abp.io and tell me what to improve.

The agent can reason about common SEO practices, but it does not have a fresh audit result. It does not know which categories scored well, which areas are weak, or whether the live page data confirms the concern.

This is similar to debugging without monitoring tools. The agent can reason, but it is reasoning from weaker evidence.

Then, With The MCP Server Enabled

Now imagine the SEO Analyzer MCP server is connected, enabled, and the relevant audit tool is enabled.

I can ask:

Run an audit on https://abp.io, rate the result, and suggest the highest-impact improvements.

This time the agent can gather the external context first. In the screenshot, the server exposes tools like run_audit_anonymous, run_audit, get_audit, list_audits, get_audit_pdf, and get_organic_traffic. The agent uses the audit tool and then explains the result in human terms.

That changes the workflow:

Run the external SEO audit.
Read the score and category breakdown.
Identify the weakest areas.
Suggest concrete technical or content improvements.
If needed, inspect the related website or documentation files.

The agent is no longer guessing from best practices alone. It can connect the outside report to the actual website and then, if the relevant files are in the solution, help improve them.

Another Example: Live Monitoring

SEO is only one example. Monitoring is another strong fit for MCP.

Prometheus MCP servers can expose tools for PromQL instant queries, range queries, metric discovery, targets, and server information. That means I can ask operational questions in natural language while the agent queries the monitoring system through MCP.

For example:

Use the Prometheus MCP server to check p95 latency, request rate, and error rate for the public web application after the last deployment. If something changed, identify the most likely area to inspect in the ABP solution.

That does not mean the agent should blindly change production behavior. It means the agent can start from live evidence: metrics, trends, targets, and recent changes. Then it can use ABP Studio context to inspect the related application, module, or configuration.

Combining MCP With ABP Studio Tools

The best part is that MCP does not replace the ABP Studio tools from the previous article. It works beside them.

In a real workflow, MCP may provide the outside signal, and ABP Studio tools may provide the inside development loop:

MCP brings in the external context.
ABP-aware reasoning maps it to the solution.
ABP Studio tools help implement and validate the change.

That is where the integration becomes more useful than a generic MCP checkbox. The agent is connected to an external tool while still understanding the ABP development environment.

How MCP Fits With Everything Else

MCP is an open standard, so connecting an MCP server is not an ABP-only idea.

Tools like Cursor, Claude, VS Code extensions, and other AI coding environments can also use MCP. That is part of its appeal. Teams can build or adopt a server once and use it across different tools.

What makes MCP especially useful in ABP Studio is the company it keeps. ABP AI Coding Agent already understands the ABP solution structure, application layers, modules, migrations, proxies, build actions, run profiles, containers, monitoring data, and official ABP documentation. MCP adds the outside world to that picture.

So I do not need to choose between:

an agent that understands ABP,
and an agent that can reach my team's external systems.

The better experience is both together, under visible configuration. Put simply:

Built-in ABP Studio tools handle the solution and runtime environment.
MCP servers handle external tools and data sources.
Rules, skills, and lessons shape how the agent behaves.
Agent mode decides whether tool use is available for the session.

Each part has a different role. Keeping those roles clear makes the agent easier to trust. This is also why I would start small in a real team workflow: one low-risk, high-value server, probably a read-only analytics, documentation, or monitoring server, with only the tools that support a clear workflow enabled.

MCP by itself is a protocol. The difference in ABP Studio is that MCP becomes part of an ABP development session. The agent can read an external SEO report or monitoring signal, but it can also understand which ABP application, module, page, or configuration owns the behavior and validate the change with ABP Studio tools.

Most real tasks are not only "call an external tool." They are more like:

Understand the requirement from outside the repository.
Find where that behavior lives in the ABP solution.
Make the smallest correct change.
Validate it in the same development environment.

MCP helps with the first part. ABP Studio AI helps connect the rest.

That makes MCP valuable not because it is another tool list, but because it extends the ABP AI Coding Agent beyond the repository without disconnecting it from the ABP workflow.

Conclusion

MCP is the agent's connection to everything that is not already inside the ABP solution.

You will not need it for every task. But when the work depends on SEO data, live metrics, external documentation, internal services, or team knowledge, MCP gives the agent a standard way to reach that context.

Deep Dive on ABP AI Agent #4: Integrated ABP Studio Tools

ABP.IO — Fri, 12 Jun 2026 05:36:58 +0000

Deep Dive on ABP AI Agent #4: Integrated ABP Studio Tools

When I use an AI coding agent, there is a point where plain code awareness is not enough.

The agent may understand the project structure. It may read the failing method. It may even guess the most likely cause of an error. But in a real development session, I usually need more than a guess. I need the latest exception, the request that caused it, the logs around it, the application that is running, the containers it depends on, the tasks I can execute, and the build result after a fix.

That is where ABP AI Coding Agent becomes different from a generic coding assistant. It is not only connected to files. It is connected to ABP Studio.

ABP Studio already knows the solution, run profiles, runnable applications, containers, tasks, monitoring data, and build actions. ABP AI Coding Agent can use that context through integrated tools when those tools are enabled. So instead of copying exception details, terminal output, container names, or build logs into the chat manually, I can let the agent work with the same ABP Studio environment I am using.

Note: ABP AI Coding Agent is available directly to ABP license holders. License holders have predefined credits so they can try it without setting up a separate AI workflow first. When those credits run out, they can buy more and continue using the same integrated experience.

Why Integrated Tools Matter

Most coding agents start from the same place: source code.

That is useful, but ABP development is not only source code. A running ABP solution has applications, modules, services, containers, database connections, migrations, logs, exceptions, requests, tasks, and build steps. When these pieces are outside the agent's reach, the developer becomes the bridge:

Copy this exception.
Paste that log.
Run this build.
Check that container.
Explain which application is currently running.
Tell the agent what failed after the last change.

Integrated ABP Studio tools reduce that manual work. They let the agent ask ABP Studio for runtime and solution information directly, within the permission boundary I choose.

The important detail is that this access is still explicit. Tools can be enabled or disabled. If I do not want the agent to use a tool, I can keep it disabled. If I want the agent to troubleshoot with runtime information, I can enable the relevant tools and ask for a more complete investigation.

That gives me a practical balance: the productivity of automation, with a visible boundary around what the agent can use.

Tool Access: What The Agent Is Allowed To Use

The tools view is the control point.

This is where ABP Studio shows the integrated tools that can be used by ABP AI Coding Agent. Some tools are for reading runtime information. Some are for interacting with applications. Some are for containers, tasks, or build actions.

The names are intentionally direct. A monitoring tool that gets exceptions is about exceptions. A build tool is about build validation. A task tool is about ABP Studio tasks. That makes the tool list easy to understand even before using it in a real prompt.

For me, the key idea is not the individual button names. It is the permission model:

If a tool is disabled, the agent should not act as if it has that information.
If a tool is enabled, the agent can use it as part of the current session.
If a task needs runtime evidence, I can enable only the tools needed for that task.

This makes ABP AI Coding Agent feel more intentional than a black box. I can decide when it should stay in code reasoning and when it should use ABP Studio's runtime view of the solution.

Monitoring Tools

Monitoring tools are the first group I reach for when something fails at runtime.

These tools help the agent inspect what happened while the application was running. In practice, this means information like exceptions , logs , events , and request details.

This is a big difference from a generic coding agent. Without monitoring tools, the agent can read the code and make a reasonable guess. With monitoring tools, it can work from the actual failure.

For example, if a page throws an exception, I can ask:

Get the latest exception from ABP Studio Monitoring and explain what failed.

If the exception tool is enabled, the agent can use that runtime signal. It can look at the exception message, stack trace, request context, and related code. Then it can connect the runtime failure to the implementation.

That changes the debugging loop:

Trigger the problem.
Ask the agent to inspect the runtime evidence.
Let it find the related code.
Apply the fix.
Validate again.

The developer no longer needs to manually copy the exception from one place and paste it into another. ABP Studio becomes part of the agent's working context and give it _ harness _!

Application Tools

Application tools connect the agent to the applications defined in the active ABP Studio run profile.

This matters because ABP solutions often contain more than one runnable application. A layered solution may have a web application, an API host, a DbMigrator, and other executable projects. A microservice solution may have several services with different roles.

ABP Studio already understands these applications through the solution and run profile. When application tools are available, the agent does not need to rediscover everything from file names or ask me which project is running. It can use ABP Studio's view of the solution.

That is useful for prompts like:

Check which application is running and use the relevant runtime information to investigate the problem.

The benefit is not only convenience. It also reduces mistakes. The agent can reason from the same run profile that I use in ABP Studio, instead of guessing from the repository structure alone.

Container Tools

Many ABP applications depend on infrastructure services while running locally.

A solution may need SQL Server, PostgreSQL, Redis, RabbitMQ, OpenIddict-related services, or other containers depending on the template and modules. When something fails, the cause is not always in application code. Sometimes a required container is not running. Sometimes the application cannot reach a dependency. Sometimes the runtime error is only a symptom of an infrastructure problem.

Container tools give the agent a way to include that part of the environment in the investigation.

Instead of asking the agent to guess why a database connection fails, I can let it check the container context that ABP Studio already has. The agent can then distinguish between:

a code problem,
a configuration problem,
a missing or stopped container,
or a dependency that is running but unhealthy.

This is one of the places where ABP Studio integration is especially valuable. General coding agents can help with Docker files or connection strings, but they usually do not know the current ABP Studio container state unless I copy it into the prompt. ABP AI Coding Agent can work closer to the actual local development environment.

Task Tools

ABP Studio tasks are another part of the development workflow that should not live outside the agent.

Tasks can represent common solution actions. They may run commands, scripts, or workflow steps that are already configured for the solution. If the team uses ABP Studio tasks to standardize local development, the agent should be able to understand and use that same layer.

That means I can ask for a workflow instead of a raw command:

Use the available ABP Studio tasks to validate this change.

The agent can work with the task names and outputs rather than asking me to remember the exact command. This is helpful in larger solutions where the correct validation step is not obvious from a single project file.

It also keeps the agent aligned with the team's development path. If ABP Studio has the task, the agent can follow that path instead of inventing a one-off command.

Build Tools

Build tools close the loop after an implementation or fix.

The agent should not only change files. It should also help verify that the change still builds.

In a generic coding agent flow, validation often depends on shell access and manually chosen commands. That can work, but it leaves more room for guessing. Which project should be built? Which solution file should be used? Is there an ABP Studio-specific build action already configured?

With ABP Studio build tools, the agent can use the build context exposed by the platform. That makes prompts like this more natural:

Apply the fix and run the available build validation.

For small changes, this may simply confirm that the project compiles. For larger changes, it can become part of a broader loop with tasks, application checks, and monitoring tools.

The important part is that the agent can move from implementation to validation without requiring me to manually transfer output between tools.

A Practical Tool Access Walkthrough

Let me make this more concrete with a small debugging scenario.

In the sample application, I deliberately added a runtime exception to the UpdateAsync method of BookAppService.cs:

throw new Exception("Sample exception for demonstrating integrated tools!");

Then I started the application from ABP Studio and triggered the related request from the browser. The only purpose of this setup is to create a real runtime failure that ABP Studio Monitoring can capture.

The interesting part is not the exception itself. The interesting part is how the agent behaves when the monitoring tool is disabled, and how that changes when the tool is enabled.

First, Without The Exception Tool

For the first run, I kept the monitoring tool that retrieves exceptions disabled.

Then I asked:

Can you get the latest exception from ABP Studio Monitoring and explain what failed?

At this point, the agent did not have direct access to the exception tool. So it tried to reason around the problem in other ways. It looked for available information, tried to inspect logs from files, and checked the codebase to understand what might be happening.

That is still useful in some cases, but it is not the best debugging flow. The agent is spending time and context trying to reconstruct a runtime failure indirectly. It may eventually find the suspicious code, but it is working from weaker evidence.

This is exactly why tool access matters. Without the monitoring tool, the agent can reason from files. With the monitoring tool, it can inspect the actual runtime failure.

Then, With The Exception Tool Enabled

For the second run, I enabled the monitoring tool that can retrieve exceptions, such as get_exceptions.

Then I asked:

Now the get_exceptions tool is enabled. Please get the latest exception from ABP Studio Monitoring, identify the failing code path, and suggest the smallest fix.

This time, the behavior was very different. The agent directly used the integrated exception tool, retrieved the exception details from ABP Studio Monitoring, and connected the runtime error to the failing code path.

It also used the enabled logging tool to verify the surrounding context instead of guessing from the source code alone.

That is the workflow I want from an integrated coding agent. It does not only say "this code looks suspicious." It checks the exception, follows the evidence, finds the source of the problem, and proposes the smallest fix.

It is also faster and more efficient. The agent does not need to spend as many tokens searching for indirect clues because ABP Studio can provide the runtime signal directly.

Adding Logs And Requests

After that, I asked the agent to use the available monitoring tools together:

Use the available monitoring tools to check the related logs and recent requests for this failure. Tell me whether they confirm the same root cause.

At this point, the agent used the enabled tools for exceptions, requests, and logs.

This is where the ABP Studio integration becomes even more valuable. A runtime problem is rarely just one line of code. There is usually a request, a log entry, an exception, and a running application context around it.

When these tools are available together, the agent can correlate them. It can say, "this request caused this exception, the logs confirm it, and this code path is responsible."

That is much better than asking the developer to copy each piece manually into the chat.

Validating The Fix

Finally, I asked the agent to validate the result:

Run the available build or application validation tools and confirm that the problem is fixed.

The agent used ABP Studio tools to stop the application, build it, and run it again.

This completes the loop. The agent did not only identify the problem. It used the integrated tools to move through the full flow:

Read the runtime exception.
Correlate it with logs and requests.
Find the failing code path.
Apply or suggest the focused fix.
Validate the application again.

That is the difference I want to highlight in this article. ABP AI Coding Agent is not only a model that can edit files. When ABP Studio tools are enabled, it can participate in the same development workflow I use: observing the running application, understanding the failure, fixing the code, and validating the result.

Why This Is Different From Generic Coding Agents

Tools like Cursor, Claude Code, and Codex are powerful. They can read code, edit files, run commands, and help with many software projects.

ABP AI Coding Agent has a different advantage: it is built for the ABP development experience.

It is aware of ABP concepts, ABP solution structure, ABP Studio run profiles, application metadata, containers, monitoring, tasks, and build actions. It is also backed by the ABP Platform: ABP Framework, ABP Commercial, ABP Suite, ABP Studio, and the workflows that connect them.

That platform context matters. When I am building an ABP solution, I do not only want a model that can write C# or TypeScript. I want an assistant that understands the way ABP applications are structured and the way ABP Studio runs them.

That makes the starting point simple: open the ABP solution, use ABP Studio, choose the right mode, enable the tools needed for the task, and work with the agent inside the platform.

Conclusion

Integrated tools make ABP AI Coding Agent more than a chat window next to the code. They give it a controlled way to work with the same ABP Studio context I already use: applications , containers , monitoring , tasks , and build actions.

-> That helps the agent move from "I think this might be the problem" to "I checked the runtime evidence, found the related code, applied the fix, and validated it."

That is the real value of this part of ABP Studio AI. It brings the coding agent closer to the full development experience, from understanding the solution to running it, observing it, fixing it, and checking the result.

As ABP Studio evolves, more tools can be added to this workflow. That means the agent can become more useful over time without changing the basic idea: ABP AI Coding Agent works best when it is not isolated from the platform, but integrated into it.

Deep Dive on ABP AI Agent #3: Rules, Skills and Lessons

ABP.IO — Thu, 11 Jun 2026 06:09:39 +0000

Deep Dive on ABP AI Agent #3: Rules, Skills and Lessons

Every new chat starts from zero.

The model can write the API, the permissions, and the UI. What disappears between sessions is everything specific to this solution: your naming rules, your feature checklist, the demo-data fix from yesterday. You end up re-teaching before you start building.

That is not an intelligence problem. The model is already capable enough. What does not carry over is the setup around it.

Agent, Model, and Harness

Three terms get mixed up constantly. Keeping them separate makes everything else in this article click.

The model is the LLM: the weights, the training data, the reasoning engine. You do not get to change it. You pick which one to use, and that is about it.

The harness is everything wrapped around the model so it can actually finish work in your environment: the system prompt, the tools it can call, the files it may read, the checks that run on its output, the limits on what it may touch, and the instructions injected into every session. A raw model is not an agent. An agent is the model plus the harness. If you are not the model, you are building the harness.

The agent is the whole system: model plus harness, running in a loop until the task is done. The behaviour you experience is dominated by the harness, not just the model. Addy Osmani puts the same idea plainly: a decent model with a great harness beats a great model with a bad harness. The gap between what today's models can do and what you actually see them do in your codebase is mostly a harness gap.

The habit that makes a harness good is simple: treat every mistake as a reason to update the setup, not just to fix the output in chat. Each time the agent gets something wrong, change what it always knows, can look up, or carries forward so it cannot repeat the same error. Do that consistently and the agent stops repeating mistakes and starts working the way your team works.

In ABP Studio AI Coding Agent , the harness includes three pieces that hold what the agent knows about your solution: Rules , Skills , and Lessons. They live under Settings > Rules & Skills.

Rules: The House Rules On The Wall

A Rule is a standing instruction that the harness injects into the agent's context on every turn of every session. In harness-engineering terms, it is always-on context injection: the same role as an AGENTS.md or CLAUDE.md at the root of a repo, except scoped to your solution or your profile inside ABP Studio.

Think of the house rules pinned to a kitchen wall: how we do things here, every shift, no exceptions. Unlike a glance at a poster, though, a Rule is not ambient background. It is read on every turn, so it costs context budget every time the agent acts.

ABP Agent already follows the framework's own conventions by default. It goes through the data layer instead of hitting the database directly, uses the built-in permission system instead of hand-rolled checks, and reads user-facing text from the translation files instead of hardcoding it. You do not write those down.

Rules are where your conventions go. The ones the framework cannot guess because they belong to your solution and your team. The good part is that these read like plain conventions any developer would recognize, not framework trivia:

New code goes in the same place, with the same naming, as the code already around it.
Every endpoint that changes data checks permissions before it does anything.
Money is stored in minor units (cents), never as a floating-point number.
API errors use our standard response shape, never ad-hoc JSON.

With those on the wall, I stop repeating them. Instead of writing this:

Add a Category screen. Use our data layer, do not query the database
directly. Check permissions on every write. Keep money in cents. Put the
files where the other features live.

I can write this:

Add a Category screen.

The conventions are not renegotiated, one prompt at a time, in every session. The agent applies them the way a teammate who has read the contributor guide would.

This matters more than it looks. A model with no standing rules does not stay neutral. It falls back on the defaults from its training data. Ask a generic model for "an endpoint that returns categories" and you often get one with the database query written straight into the handler, because that is the most common shape on the public internet. Rules steer the agent's output back toward your codebase.

One caution: treat the rule list like a pilot's checklist, not a style guide. A Rule is injected on every turn, so keep the list short. Every line should earn its place, ideally traceable to a real failure or a hard constraint you cannot ignore. If a line does not change what the agent produces, it is noise, and it dilutes the rules that actually matter.

You also choose where a rule is saved. Global rules sit under your user profile and apply to every solution on your machine. Solution rules apply only to the current solution, and only while it is open.

Skills: Recipes You Pull Off The Shelf

A Skill is the same kind of note as a Rule, but loaded only when the task calls for it. The harness keeps a short description of each skill in context at all times; the agent reads the full text only when that description matches what you asked it to do. Harness engineers call this progressive disclosure : reveal instructions and detail only when they are needed, instead of stuffing everything into the opening prompt.

A recipe is not pinned to the wall. It sits in a drawer, and the cook pulls it out only when making that dish. That is a Skill.

In ABP Studio, a rule and a skill are the same kind of note with one switch between them.

You write a name (which becomes the file name) and some content, then set Always Apply. Turn it on and the note is a Rule, always in context. Turn it off and the note is a Skill, fetched on demand. So if a skill turns out to be something the agent should never skip, you flip one switch and it becomes a rule.

My favorite example of a skill is a "build a feature end to end" checklist: the ordered steps your team follows to ship one complete feature. The data model comes first, then the data access layer, then the application service, then the API, then the translations, then the UI, and finally the demo data. Write it once, and the agent follows it whenever it builds a feature, instead of inventing its own order each time.

Writing a skill is like writing an onboarding note for a new teammate. You are not making them smarter. You are saving them the week it would take to work out how your team does this one thing.

A skill can be long without slowing anything down. The agent sees only the short description of each skill at all times, and reads the full text only when the description matches the task. The detail stays in the drawer until it is needed.

Skills are also portable. A skill is plain Markdown, so you can import one written elsewhere instead of retyping it.

You point the importer at a file or a folder of .md files and choose whether they go into the current solution or your global profile. A procedure one person worked out can travel to the rest of the team, or to your next solution.

A simple test for which one to reach for:

If it should hold no matter what you are doing, it is a Rule. ("Always return errors in our standard shape.")
If it is a procedure you follow only for a certain kind of task, it is a Skill. ("Here is our checklist for adding a feature end to end.")

Lessons: What The Agent Learns On Its Own

Rules and Skills are written by a person. Lessons are written by the agent.

Think of a shift handoff log in the kitchen: after something goes wrong, someone writes down what happened and what to do differently next time. The next cook reads it before repeating the same work. In ABP Studio, you correct the mistake; the agent records the verified fix so future sessions do not trip over it again. That entry is a Lesson.

When the agent gets something wrong and is corrected, by you, by a failing build, or by the official ABP documentation, it can record the correction as a short, verified note. The harness carries that note into later turns and later sessions as high-priority context. That is the ai-learned-lessons entry you saw in the settings list, growing as the agent works in your solution.

The idea behind it is simple: when the agent gets something wrong, fix it once so it never gets it wrong the same way again. You already do a version of this when you edit a notes file by hand. Lessons do the recording for you, at the moment of the correction, when the reason is still fresh and you would otherwise forget to write it down.

Here is the shape of a real one. I ask the agent to add a Category screen. It builds the data model, the API, and the UI, but forgets to grant the new permission in the demo data. The screen compiles, the API responds, everything looks finished, and the only symptom is that real users get "access denied." I correct it, the agent fixes the demo data, and it records a note: in this solution, a new permission is not done until it is granted in the demo data. Next time, it remembers.

A Lesson is not a general fact about ABP. The documentation already covers that, and the agent reads it. A Lesson is a solution-specific, verified correction: the kind of knowledge a team usually keeps in people's heads and loses when they move on. Here it is written down the moment it is learned, instead of weeks later, if ever.

When To Use Which?

Once the three are clear, they sort themselves out:

| Mechanism | Who writes it | When it loads | Answers | | --- | --- | --- | --- | | Rules | You | Always, every turn | "What must always be true here?" | | Skills | You | When relevant to the task | "How do we do this kind of task?" | | Lessons | The agent | In later sessions, as high-priority context | "What did we get wrong before in this solution?" |

They feed into each other. A Lesson that keeps coming back is a sign it should be promoted. If the agent records the same correction again and again, it is no longer a one-off note. It belongs in a Rule, if it is an always-true convention, or in a Skill, if it is a procedure. Knowledge tends to move from Lessons toward Rules and Skills: the agent finds the pattern by tripping over it, and you write it down properly once it has earned the spot.

Keep an eye on the budget, because all three share the same limited space, the context window. Rules cost the most, since they are always present, so an overstuffed rule list weighs down every turn and crowds out the rules that matter. Skills are cheaper, paid for only when used, which is a good reason to move anything situational out of Rules and into a Skill. Lessons add up too, so clear out the stale ones now and then. The point is not to write down everything you know. It is to write down the few things that change what the agent produces, and put each one where it loads at the right time.

Why This Is Different From Generic Coding Agents?

To be fair, the ideas themselves are not unique to ABP. Tools like Cursor, Claude Code, Codex, and Windsurf are strong general-purpose coding tools, and they already have always-on instruction files and on-demand skill files. If all you compare is whether a tool can hold rules and skills, there is no real difference, and I would not pretend otherwise.

The difference is in the two places where a generic tool has to guess.

The first is memory of its own mistakes. In most tools, remembering a past mistake means you stop and edit a memory file by hand. Lessons remove that step. The agent records the correction itself, the moment it happens, so the knowledge survives without you having to maintain it.

The second, and the one that matters most, is what all of this sits on. A generic instruction file can say "use the data layer," but the tool still has to read your files and guess what the data layer is and where it lives. ABP Agent does not guess. It starts every session with an ABP-aware map of your solution, and when it is unsure how something should be done, it checks the official ABP documentation instead of the average of the public internet. So the rules and skills you write are not hints dropped into a tool that barely understands the project. They are backed by one that already knows the framework underneath them.

There is also a smaller convenience worth a line: a rule and a skill are the same note with one switch between them, scoped to the solution or your profile from the same place, instead of two separate file formats to keep track of.

Conclusion

It is best to see the three as one system, not three switches.

Rules hold the conventions you refuse to repeat.
Skills hold the procedures you want to reuse.
Lessons hold the corrections the agent learns as it works.

Together they answer the blank-memory problem. They do not give the model new weights. They inject, at the start of each session, the smallest useful set of instructions so the agent can work as if it has been here before.

A generic agent with no harness tuning stays roughly as capable on its thousandth task in your codebase as on its first. With Rules, Skills, and Lessons, ABP Agent accumulates solution-specific knowledge over time, especially through Lessons and the promotions you make from them.

That is the real value: not just an AI that writes code, but one that learns how your solution is built and keeps that knowledge from one session to the next.

Deep Dive on ABP AI Agent #2: Supported AI Models in ABP Studio + Usage Recommendations

ABP.IO — Wed, 10 Jun 2026 05:51:56 +0000

Deep Dive on ABP AI Agent #2: Supported AI Models in ABP Studio + Usage Recommendations

There is one question I ask almost as often as "Which mode should I use?":

Which model should do this work?

At first, it is tempting to answer that question by always choosing the strongest model in the list. That feels safe. If a model is more capable, why not use it for everything?

In real work, I do not think about it that way.

When I use ABP Studio AI , the model choice is part of the workflow. Some tasks need careful reasoning. Some need speed. Some need a large context window. Some need image support because the browser or a screenshot is involved. Some are small text-processing tasks where using the most capable model would only make the work slower and more expensive.

So I treat model selection as a practical decision, not a trophy selection.

What ABP Studio Supports Today

ABP Studio gives me a curated model setup by default. It keeps the first experience simple, while still letting me choose from a broader model catalog when I want to tune the setup for a specific kind of work.

The important word here is focused.

ABP Studio does not treat every model as an equally good choice for agent work. A coding agent needs things like a useful context window, tool support, text output, and reliable behavior in repeated agent loops. Studio keeps the model experience closer to that reality.

The built-in model set currently includes:

| Model | How I think about it | | --- | --- | | Claude Sonnet 4.6 | The default main model for day-to-day Ask, Plan, and Agent work. | | Claude Haiku 4.5 | A fast supporting model for research, browser work, and lightweight text processing. | | Claude Opus 4.7 | A stronger option when the task needs deeper reasoning or more careful review. | | GPT-5.5 | Another strong option for main conversations or review-style work. | | GLM-5.1 | A text/code option for tasks that do not need image input. |

I do not read this list as a ranking. I read it as the default toolbox.

And it is not a closed box. If I need a different model for a specific task, I can open the Models settings, search the catalog, filter by category, and add more models to my selection.

That is an important distinction. The built-in models are there so I can start with sensible defaults. They are not there to force every team, every solution, or every workflow into the same model choices.

The Main Model

The main model is the one I feel most directly in the conversation.

It is used when I ask questions, create plans, or let ABP Agent work through an implementation. This is the model behind the normal flow of the chat.

For most work, I keep a balanced model as the main model. A Sonnet-style model is a good default because it is capable enough for real development tasks without making every small question feel heavy.

This is the model I use for:

Understanding a module or package
Planning a feature before editing code
Applying a reviewed plan
Fixing ordinary build or test failures
Making changes where the expected result is easy to review

When the task gets broader, I become more intentional.

If I am asking ABP Agent to reason across several modules, plan a risky refactor, review architecture, or inspect a subtle regression, I am more willing to switch to a stronger model. The extra capability is useful when the cost of a shallow answer is high.

For a quick localization change or a small DTO update, that same choice can be wasteful. The strongest model is not always the best model for the moment.

Role-Based Models

One detail I like in ABP Studio AI is that model selection is not only one global dropdown.

Studio separates the main conversation model from supporting model roles. That means I can keep the main model strong enough for the conversation while using lighter models for background work.

The roles are easier to understand if I describe them by how they feel in daily use.

Main Model is the model I am actively talking to. It carries the normal Ask, Plan, and Agent experience.

Research Model is for research and ABP documentation searcher work. I usually keep this lightweight because research often involves gathering, narrowing, and summarizing context before the main model decides what to do with it.

Browser Model is used by the browser subagent in Agent mode. This role should stay fast and practical. When browser screenshots are involved, I choose a model that supports image input. A text-only model may be fine for code, but it is not the right fit when the work depends on seeing the UI.

Text Processor Model is for smaller language tasks such as summarizing errors, generating commit messages, or consolidating learned lessons. This is exactly where I do not want to spend the most capable model every time.

The Git Review model is separate too.

For AI Review, I like the "Ask me every time" behavior. Some reviews are routine. Some reviews deserve a stronger model because the change is large, security-sensitive, or touches architecture. Asking each time keeps that decision close to the actual change.

If a team wants consistent review behavior, a fixed review model also makes sense. The key is that Git Review does not have to silently follow the same model I use for ordinary chat.

How I Choose In Practice

For quick questions, I use the default main model.

If I am asking "Where is this permission defined?" or "Why does this module reference that package?", I do not need to overthink the model. I want a clear answer and maybe a few source references.

For planning larger work, I use a stronger main model when the decision matters.

Plan mode is where the model can save me from an expensive wrong turn. If the change crosses layers, modules, permissions, UI, or database behavior, I prefer a model that can hold more context and reason carefully. I still narrow the scope where possible, because a focused prompt usually beats a huge unfocused one.

For implementation, I care about reliability more than raw size.

Agent mode is not only about generating code. It is about reading the solution, editing files, running checks, seeing failures, and trying again. A good main model should follow instructions consistently and use tools well. For supporting roles, I usually keep the lighter defaults.

For UI and browser tasks, I check image support.

If the task involves screenshots, browser interaction, visual verification, or UI state, the browser model needs to be able to understand images. This is one reason I do not treat every text/code model as interchangeable.

For reviews, I choose based on risk.

A small formatting or localization change does not need the same review setup as a large change in authorization, multi-tenancy, persistence, or distributed behavior. For deeper reviews, I am willing to use a stronger model because the goal is not speed. The goal is to catch what I missed.

For cost and latency, I avoid using the strongest model everywhere.

This is not only about credits. It is also about pace. If every background task uses a heavy model, the development loop feels slower. Keeping lightweight models for lightweight jobs makes ABP Studio AI feel more responsive.

A Simple Rule

The model name matters less than the job.

When I choose a model in ABP Studio AI, I usually ask:

| Situation | Model choice I prefer | | --- | --- | | Normal Ask, Plan, or Agent work | Balanced main model | | Broad planning or risky implementation | Stronger main model | | Research and documentation lookup | Lightweight supporting model | | Browser tasks with screenshots | Vision-capable browser model | | Error summaries and commit messages | Lightweight text processor model | | Important AI Review | Stronger model or ask each time |

That keeps the experience practical.

Modes decide how much action I want: Ask, Plan, or Agent.

Models decide which brain should handle the work.

When those two choices are made intentionally, ABP Studio AI feels less like one generic AI button and more like a set of tools I can tune for the task in front of me.

Deep Dive on ABP AI Agent #1: Agent, Plan and Ask Modes

ABP.IO — Tue, 09 Jun 2026 07:52:20 +0000

Deep Dive on ABP AI Agent #1: Agent, Plan and Ask Modes

There is a small question I like to answer before I type anything into ABP Agent :

Do I want an answer, a plan, or action?

That question looks simple, but it changes the whole experience. Sometimes I am only trying to understand why a module is structured a certain way. Sometimes I already know the direction, but I want the implementation path checked before touching files. And sometimes the task is clear enough that I want ABP Agent to do the work, run the checks, and iterate with me.

That is where the three modes in ABP Studio AI become more than labels. They help me choose the right level of trust, risk, and action for the moment.

Ask Mode: When I Want To Understand

Ask is the mode I reach for when I want to stay in learning mode.

It is useful when I am reading a solution and want to ask questions like:

What is this module responsible for?
Why is this permission checked here?
How does this application service relate to the domain layer?
What would happen if I changed this setting, dependency, or flow?
Which ABP concept should I use for this requirement?

The important part is that Ask mode is read-only. I can explore the codebase, ABP concepts, architecture, or possible approaches without worrying that files will be changed as a side effect of the conversation.

That makes it a comfortable starting point. I do not need to prepare a perfect prompt. I can ask a rough question, follow up with more context, and slowly turn uncertainty into something clearer.

For me, Ask mode is especially helpful when I join a solution after some time away. Instead of jumping between files and trying to rebuild the story manually, I can ask ABP Agent to explain the shape of the solution in the language of ABP: modules, layers, permissions, application services, entities, settings, events, and runtime pieces.

Plan Mode: When I Want To Think Before Changing Code

Plan is the mode I use when the next step is probably implementation, but I do not want to start editing yet.

This is the middle ground between a conversation and a code change. ABP Agent can inspect the solution in a read-only way, ask clarifying questions when the requirement is not clear enough, and produce a structured plan before any file is modified.

That changes the feeling of working with AI. Instead of saying "go build this" and reviewing only the result, I can review the approach first:

Which files will likely be affected?
Which ABP layers are involved?
Does the implementation path match the existing solution style?
Are there missing decisions before the work starts?
Is this a small change, or is it actually a larger workflow?

This is useful for changes that cross boundaries: adding a new entity, adjusting an application service, introducing a permission, changing a UI flow, or touching more than one module. Those are exactly the moments where I want a second pass before code starts moving.

When a plan is active, ABP Studio gives me clear actions around it. I can view the plan, detach it if it is no longer the right direction, or apply it with Agent mode when I am ready to move from planning to implementation.

The small detail I like here is that the plan does not disappear into the chat history. It becomes something I can review and intentionally carry into the next step.

Agent Mode: When I Am Ready For Action

Agent is the mode I choose when I am ready to let ABP Agent work on the solution.

This is the action mode. ABP Agent can edit files, run commands, build projects, use ABP Studio tasks, and iterate when something fails. It is the right choice when the task is clear enough and I am comfortable letting the agent make changes that I will review afterward.

For small trusted tasks, I may go directly to Agent mode:

Add a missing localization entry
Fix a straightforward build error
Update a simple DTO mapping
Add a validation rule that matches an existing pattern
Apply a plan that I have already reviewed

For larger work, I prefer not to start here. Agent mode is powerful, and power is better when it is intentional. If I am not sure about the shape of the change, I usually start with Ask or Plan first.

A Practical Workflow

The modes are most useful when I treat them as a workflow, not as three disconnected buttons.

For larger changes, my usual flow is:

Ask to understand the area and the existing conventions.
Plan to turn the requirement into a reviewable implementation path.
Agent to apply the plan, build, and iterate.

For learning, I often stay entirely in Ask mode. If I am trying to understand ABP multi-tenancy behavior, module dependencies, permission definitions, or why a solution is organized a certain way, there is no need to involve file changes.

For small tasks, I may go directly to Agent mode. The key is that I already know what I want, the risk is low, and the expected result is easy to review.

Here is the simple rule I keep in mind:

| Situation | Mode I Choose | Why | | --- | --- | --- | | I need an explanation | Ask | It keeps the conversation read-only. | | I need a direction before implementation | Plan | It gives me a reviewable path before changes. | | I am ready for ABP Agent to work | Agent | It can edit, build, run tasks, and iterate. |

Why This Matters

AI-assisted development can feel too fast when the tool moves from idea to code before I have decided what kind of help I actually need.

The three modes slow that moment down in a good way. They let me say:

"Just explain this."
"Think through the change first."
"Now implement it."

That separation makes the work feel more intentional. It also makes the output easier to review, because the mode already tells me what kind of result I should expect.

Ask gives me understanding. Plan gives me a path. Agent gives me action.

Used together, they make ABP Studio AI feel less like a single big button and more like a development partner that can adapt to the level of confidence I have at each step.

Implement Automatic Method-Level Caching in ABP Framework

ABP.IO — Mon, 08 Dec 2025 07:16:29 +0000

Implement Automatic Method-Level Caching in ABP Framework

Caching is one of the most effective ways to improve application performance, but implementing it manually for every method can be tedious and error-prone. What if you could cache method results automatically with just an attribute? In this article, we'll explore how to build an automatic method-level caching system in ABP Framework that handles cache invalidation, supports multiple scopes, and integrates seamlessly with your existing application.

By the end of this guide, you'll understand how to implement attribute-based caching that automatically invalidates when entities change, supports user-specific and global caching scopes, and provides built-in metrics for monitoring cache performance.

💡 Complete Implementation Available : This article is based on a working demo project. You can find the complete implementation in the AbpAutoCacheDemo repository, with the core AutoCache library implementation available in this commit.

What is Automatic Method-Level Caching?

Automatic method-level caching is a technique that intercepts method calls and caches their results without requiring manual cache management code. Instead of writing cache logic in every method, you simply decorate methods with attributes that define caching behavior.

The key benefits include:

Reduced Boilerplate: No repetitive cache management code in your business logic
Consistent Caching Strategy: Centralized cache configuration and behavior
Smart Invalidation: Automatic cache clearing when related entities change
Multiple Scopes: Support for global, user-specific, and entity-specific caching
Built-in Monitoring: Track cache hits, misses, and performance metrics

Architecture Overview

The automatic caching system consists of several key components working together:

Core Components:

CacheAttribute: The attribute you apply to methods to enable automatic caching
AutoCacheInterceptor: Intercepts method calls and handles cache operations
AutoCacheManager: Manages cache storage, retrieval, and key generation
IAutoCacheKeyManager: Handles cache key mapping and invalidation
AutoCacheInvalidationHandler: Listens to entity changes and clears related caches

This architecture leverages ABP's dynamic proxy system and event bus to provide seamless caching without modifying your business logic.

Prerequisites

Before implementing automatic caching, ensure you have:

ABP Framework 10.0 or later

Implementation

📦 Repository Structure : The complete implementation is available in the AbpAutoCacheDemo repository. The AutoCache library is located in the src/AutoCache folder, making it easy to extract and reuse in your own projects.

Step - 1: Create the AutoCache Module

First, let's create a separate module for our caching infrastructure. This makes it reusable across projects.

Step - 1: Create the AutoCache Module

First, let's create a separate module for our caching infrastructure. This makes it reusable across projects.

Create AutoCache.csproj:

<Project Sdk="Microsoft.NET.Sdk">
    <PropertyGroup>
        <TargetFramework>net10.0</TargetFramework>
        <Nullable>enable</Nullable>
    </PropertyGroup>

    <ItemGroup>
        <PackageReference Include="Volo.Abp.Caching.StackExchangeRedis" Version="10.0.0" />
        <PackageReference Include="Volo.Abp.Core" Version="10.0.0" />
        <PackageReference Include="Volo.Abp.Ddd.Domain" Version="10.0.0" />
    </ItemGroup>
</Project>

Create the module class AutoCacheModule.cs:

using Microsoft.Extensions.DependencyInjection;
using Volo.Abp.Caching.StackExchangeRedis;
using Volo.Abp.Domain;
using Volo.Abp.Modularity;

namespace AutoCache;

[DependsOn(typeof(AbpDddDomainModule), typeof(AbpCachingStackExchangeRedisModule))]
public class AutoCacheModule : AbpModule
{
    public override void PreConfigureServices(ServiceConfigurationContext context)
    {
        context.Services.OnRegistered(AutoCacheRegister.RegisterInterceptorIfNeeded); // 👈 Register interceptor
    }
}

This module automatically registers the cache interceptor for any class that uses the CacheAttribute.

Step - 2: Define the Cache Attribute

The CacheAttribute is the core of our automatic caching system. It specifies which entities affect the cache and what scope to use.

Create CacheAttribute.cs:

using System;
using Volo.Abp.Domain.Entities;

namespace AutoCache;

[AttributeUsage(AttributeTargets.Method)]
public class CacheAttribute : Attribute
{
    /// <summary>
    /// Entity types that affect this cache. When these entities change, the cache will be invalidated.
    /// </summary>
    public Type[] InvalidateOnEntities { get; set; }

    /// <summary>
    /// Scope of the cache (Global, CurrentUser, AuthenticatedUser, or Entity)
    /// </summary>
    public AutoCacheScope Scope { get; set; } = AutoCacheScope.Global;

    /// <summary>
    /// Absolute expiration time relative to now in milliseconds (0 = use default, -1 = disabled)
    /// </summary>
    public long AbsoluteExpirationRelativeToNow { get; set; }

    /// <summary>
    /// Sliding expiration time in milliseconds (0 = use default, -1 = disabled)
    /// </summary>
    public long SlidingExpiration { get; set; }

    public bool ConsiderUow { get; set; }

    public string AdditionalCacheKey { get; set; }

    public CacheAttribute(params Type[] invalidateOnEntities) // 👈 Specify entities that trigger cache invalidation
    {
        foreach (var entityType in invalidateOnEntities)
        {
            ArgumentNullException.ThrowIfNull(entityType);
            if (!typeof(IEntity).IsAssignableFrom(entityType))
            {
                throw new ArgumentException($"Type {entityType.FullName} must implement IEntity interface.");
            }
        }
        InvalidateOnEntities = invalidateOnEntities;
    }
}

Key Properties:

InvalidateOnEntities: Array of entity types that, when modified, will clear this cache
Scope: Determines cache visibility (Global, CurrentUser, AuthenticatedUser, Entity)
AbsoluteExpirationRelativeToNow / SlidingExpiration: Control cache lifetime

Step - 3: Define Cache Scopes

Cache scopes determine how cache entries are partitioned. Create AutoCacheScope.cs:

using System;

namespace AutoCache;

[Flags]
public enum AutoCacheScope
{
    /// <summary>
    /// Cache is shared globally across all users
    /// </summary>
    Global,

    /// <summary>
    /// Cache is scoped to the current user (based on user ID)
    /// </summary>
    CurrentUser,

    /// <summary>
    /// Cache is scoped to authenticated vs unauthenticated users
    /// </summary>
    AuthenticatedUser,

    /// <summary>
    /// Cache is scoped to the primary key of the entity involved
    /// </summary>
    Entity
}

When to Use Each Scope:

Global: For data that's the same for all users (e.g., configuration, public lists)
CurrentUser: For user-specific data (e.g., user profile, user's orders)
AuthenticatedUser: For data that differs between authenticated and anonymous users
Entity: For data tied to a specific entity instance (e.g., book details by ID)

Step - 4: Implement the Cache Interceptor

The interceptor is the heart of automatic caching. It intercepts method calls, checks the cache, and stores results. Create AutoCacheInterceptor.cs:

using System;
using System.Collections.Concurrent;
using System.Linq;
using System.Reflection;
using System.Threading.Tasks;
using Microsoft.Extensions.Caching.Distributed;
using Microsoft.Extensions.Logging;
using Microsoft.Extensions.Options;
using Volo.Abp.DependencyInjection;
using Volo.Abp.DynamicProxy;

namespace AutoCache;

public class AutoCacheInterceptor : AbpInterceptor, ITransientDependency
{
    private readonly ILogger<AutoCacheInterceptor> _logger;
    private readonly AutoCacheOptions _options;
    private static readonly MethodInfo GetOrAddCacheAsyncMethod;
    private readonly AutoCacheManager _autoCacheManager;
    private static readonly ConcurrentDictionary<Type, MethodInfo> MethodCache = new();

    static AutoCacheInterceptor()
    {
        GetOrAddCacheAsyncMethod = typeof(AutoCacheInterceptor).GetMethod(
            nameof(GetOrAddCacheAsync),
            BindingFlags.NonPublic | BindingFlags.Instance
        )!;
    }

    public AutoCacheInterceptor(
        ILogger<AutoCacheInterceptor> logger,
        IOptions<AutoCacheOptions> options, 
        AutoCacheManager autoCacheManager)
    {
        _logger = logger;
        _autoCacheManager = autoCacheManager;
        _options = options.Value;
    }

    public override async Task InterceptAsync(IAbpMethodInvocation invocation)
    {
        // Check if caching is enabled and method has [Cache] attribute
        if(!_options.Enabled || 
           invocation.Method.GetCustomAttributes(typeof(CacheAttribute), true).FirstOrDefault() 
           is not CacheAttribute attribute)
        {
            await invocation.ProceedAsync(); // 👈 No caching, proceed normally
            return;
        }

        var proceeded = false;

        try
        {
            // Create generic method based on return type
            var genericMethod = MethodCache.GetOrAdd(invocation.Method.ReturnType, t =>
            {
                var isGenericTask = t.IsGenericType && t.GetGenericTypeDefinition() == typeof(Task<>);
                var resultType = isGenericTask ? t.GetGenericArguments()[0] : t;
                return GetOrAddCacheAsyncMethod.MakeGenericMethod(resultType);
            });

            // Execute cache logic
            (var result, proceeded) = await (Task<(object, bool)>)genericMethod.Invoke(this, [invocation, attribute])!;
            invocation.ReturnValue = result; // 👈 Set cached or fresh result
        }
        catch (Exception e)
        {
            _logger.LogError(e, "Error occurred while caching method {MethodName}", invocation.Method.Name);

            if(e is AutoCacheExceptionWrapper exceptionWrapper)
            {
                if (_options.ThrowOnError)
                {
                    throw exceptionWrapper.OriginalException;
                }

                _logger.LogWarning(
                    "Cache operation failed, falling back to method execution for {MethodName}",
                    invocation.Method.Name
                );
            }

            if (!proceeded && invocation.ReturnValue == null)
            {
                await invocation.ProceedAsync(); // 👈 Fallback to actual method execution
            }
        }
    }

    private async Task<(object?, bool)> GetOrAddCacheAsync<TResult>(
        IAbpMethodInvocation invocation, 
        CacheAttribute attribute)
    {
        var proceeded = false;
        var result = await _autoCacheManager.GetOrAddAsync(
            invocation.TargetObject, 
            Factory, 
            invocation.Arguments, 
            () => new DistributedCacheEntryOptions
            {
                AbsoluteExpirationRelativeToNow = GetExpiration(
                    attribute.AbsoluteExpirationRelativeToNow, 
                    _options.DefaultAbsoluteExpirationRelativeToNow),
                SlidingExpiration = GetExpiration(
                    attribute.SlidingExpiration, 
                    _options.DefaultSlidingExpiration)
            }, 
            attribute.InvalidateOnEntities, 
            attribute.Scope, 
            attribute.ConsiderUow, 
            attribute.AdditionalCacheKey, 
            invocation.Method.Name);

        return (result, proceeded);

        async Task<TResult> Factory()
        {
            await invocation.ProceedAsync(); // 👈 Execute actual method on cache miss
            proceeded = true;
            return (TResult)invocation.ReturnValue;
        }
    }

    private static TimeSpan? GetExpiration(long milliseconds, long defaultValue)
    {
        return milliseconds switch
        {
            0 => defaultValue > 0 ? TimeSpan.FromMilliseconds(defaultValue) : null,
            < 0 => null,
            _ => TimeSpan.FromMilliseconds(milliseconds)
        };
    }
}

The interceptor intelligently determines whether to serve cached data or execute the actual method.

Step - 5: Implement the Cache Manager

The AutoCacheManager handles the actual cache operations. Create a simplified version:

using System;
using System.Runtime.CompilerServices;
using System.Threading.Tasks;
using Microsoft.Extensions.Caching.Distributed;
using Microsoft.Extensions.Logging;
using Volo.Abp.DependencyInjection;
using Volo.Abp.DynamicProxy;
using Volo.Abp.Users;

namespace AutoCache;

public class AutoCacheManager : IScopedDependency
{
    private readonly IAutoCacheKeyManager _autoCacheKeyManager;
    private readonly ICurrentUser _currentUser;
    private readonly ILogger<AutoCacheManager> _logger;
    private readonly IAutoCacheMetrics _metrics;
    private readonly AutoCacheOptions _options;

    public AutoCacheManager(
        IAutoCacheKeyManager autoCacheKeyManager, 
        ICurrentUser currentUser,
        ILogger<AutoCacheManager> logger,
        IAutoCacheMetrics metrics,
        IOptions<AutoCacheOptions> options)
    {
        _autoCacheKeyManager = autoCacheKeyManager;
        _currentUser = currentUser;
        _logger = logger;
        _metrics = metrics;
        _options = options.Value;
    }

    public async Task<TResult> GetOrAddAsync<TResult>(
        object? caller,
        Func<Task<TResult>> func,
        object?[]? parameters = null,
        Func<DistributedCacheEntryOptions>? optionsFactory = null,
        Type[]? invalidateOnEntities = null,
        AutoCacheScope scope = AutoCacheScope.Global,
        bool considerUow = false,
        string? additionalCacheKey = null,
        [CallerMemberName] string methodName = "")
    {
        if (!_options.Enabled)
        {
            return await func(); // 👈 Caching disabled, execute directly
        }

        var callerType = caller != null ? ProxyHelper.GetUnProxiedType(caller) : GetType();
        parameters ??= [];

        // Generate unique cache key based on method, parameters, and scope
        var cacheKey = GenerateCacheKey<TResult>(
            callerType.Name, 
            additionalCacheKey, 
            methodName, 
            parameters, 
            scope);

        var (cachedResult, exception, wasHit) = await GetOrAddCacheAsync(
            cacheKey,
            func,
            optionsFactory,
            considerUow
        );

        // Record metrics
        if (wasHit)
        {
            _metrics.RecordHit(cacheKey);
        }
        else
        {
            _metrics.RecordMiss(cacheKey);
        }

        if (exception != null)
        {
            _metrics.RecordError(cacheKey, exception);

            if (_options.ThrowOnError)
            {
                throw exception;
            }
        }

        return cachedResult;
    }

    private string GenerateCacheKey<TResult>(
        string callerTypeName,
        string? additionalCacheKey,
        string methodName,
        object?[] parameters,
        AutoCacheScope scope)
    {
        var keyBuilder = new StringBuilder();
        keyBuilder.Append($"{callerTypeName}:{methodName}");

        // Add parameters to key
        foreach (var param in parameters)
        {
            keyBuilder.Append($":{param}");
        }

        // Add scope-specific segments
        if (scope.HasFlag(AutoCacheScope.CurrentUser) && _currentUser.Id.HasValue)
        {
            keyBuilder.Append($":user:{_currentUser.Id}"); // 👈 User-specific cache key
        }

        if (scope.HasFlag(AutoCacheScope.AuthenticatedUser))
        {
            keyBuilder.Append($":auth:{_currentUser.IsAuthenticated}");
        }

        if (!string.IsNullOrEmpty(additionalCacheKey))
        {
            keyBuilder.Append($":{additionalCacheKey}");
        }

        return keyBuilder.ToString();
    }

    // Additional methods for cache retrieval and storage...
}

The manager generates unique cache keys based on method signatures, parameters, and scope settings.

Step - 6: Implement Cache Invalidation

When entities change, related caches must be cleared. Create AutoCacheInvalidationHandler.cs:

using System;
using System.Threading.Tasks;
using Microsoft.Extensions.Logging;
using Volo.Abp.Domain.Entities;
using Volo.Abp.Domain.Entities.Events;
using Volo.Abp.EventBus;
using Volo.Abp.Uow;

namespace AutoCache;

public class AutoCacheInvalidationHandler<TEntity> : 
    ILocalEventHandler<EntityChangedEventData<TEntity>> 
    where TEntity : class, IEntity
{
    private readonly IAutoCacheKeyManager _autoCacheKeyManager;
    private readonly ILogger<AutoCacheInvalidationHandler<TEntity>> _logger;
    private readonly IUnitOfWorkManager _unitOfWorkManager;

    public AutoCacheInvalidationHandler(
        IAutoCacheKeyManager autoCacheKeyManager, 
        ILogger<AutoCacheInvalidationHandler<TEntity>> logger,
        IUnitOfWorkManager unitOfWorkManager)
    {
        _autoCacheKeyManager = autoCacheKeyManager;
        _logger = logger;
        _unitOfWorkManager = unitOfWorkManager;
    }

    public async Task HandleEventAsync(EntityChangedEventData<TEntity> eventData)
    {
        try
        {
            var entityType = typeof(TEntity);
            var context = new RemoveCacheKeyContext 
            { 
                Keys = eventData.Entity.GetKeys()! 
            };

            // Clear cache after unit of work completes
            if(_unitOfWorkManager.Current != null)
            {
                _unitOfWorkManager.Current.OnCompleted(async () =>
                {
                    await _autoCacheKeyManager.RemoveCacheAndCacheKeys(entityType, context); // 👈 Invalidate cache
                });
            }
            else
            {
                await _autoCacheKeyManager.RemoveCacheAndCacheKeys(entityType, context);
            }
        }
        catch (Exception e)
        {
            _logger.LogError(
                e, 
                "Error occurred while clearing cache for entity type {EntityType}", 
                typeof(TEntity).FullName
            );
        }
    }
}

This handler listens to entity change events and automatically clears related caches. The invalidation happens after the unit of work completes to ensure data consistency.

Step - 7: Configure AutoCache in Your Application

Add the AutoCacheModule to your application module dependencies:

[DependsOn(
    typeof(AutoCacheModule), // 👈 Add AutoCache module
    typeof(AbpCachingStackExchangeRedisModule),
    // ... other modules
)]
public class YourApplicationModule : AbpModule
{
    public override void ConfigureServices(ServiceConfigurationContext context)
    {
        Configure<AutoCacheOptions>(options =>
        {
            options.Enabled = true; // 👈 Enable caching
            options.DefaultAbsoluteExpirationRelativeToNow = 3600000; // 1 hour
            options.DefaultSlidingExpiration = 600000; // 10 minutes
            options.ThrowOnError = false; // Fallback to method execution on cache errors
        });

        // Configure Redis (if using distributed cache)
        Configure<AbpDistributedCacheOptions>(options =>
        {
            options.KeyPrefix = "YourApp:";
        });
    }
}

Step - 8: Use Automatic Caching in Application Services

Now comes the easy part - using automatic caching! Simply add the [Cache] attribute to your methods:

using AutoCache;

[Authorize(AutoCacheDemoPermissions.Books.Default)]
public class BookAppService : ApplicationService, IBookAppService
{
    private readonly IRepository<Book, Guid> _repository;
    private readonly AutoCacheManager _autoCacheManager;

    public BookAppService(IRepository<Book, Guid> repository, AutoCacheManager autoCacheManager)
    {
        _repository = repository;
        _autoCacheManager = autoCacheManager;
    }

    // Cache this method, invalidate when Book entity changes
    [Cache(typeof(Book), Scope = AutoCacheScope.Global)]
    public virtual async Task<BookDto> GetAsync(Guid id)
    {
        // You can also use AutoCacheManager directly for nested caching
        var book = await _autoCacheManager.GetOrAddAsync(
            this, 
            async () => await _repository.GetAsync(id), 
            [id], // 👈 Method parameters
            invalidateOnEntities: [typeof(Book)], 
            scope: AutoCacheScope.Entity);

        return ObjectMapper.Map<Book, BookDto>(book!);
    }

    // Cache book list, invalidate when any Book changes
    [Cache(typeof(Book))]
    public virtual async Task<PagedResultDto<BookDto>> GetListAsync(PagedAndSortedResultRequestDto input)
    {
        var queryable = await _repository.GetQueryableAsync();
        var query = queryable
            .OrderBy(input.Sorting.IsNullOrWhiteSpace() ? "Name" : input.Sorting)
            .Skip(input.SkipCount)
            .Take(input.MaxResultCount);

        var books = await AsyncExecuter.ToListAsync(query);
        var totalCount = await AsyncExecuter.CountAsync(queryable);

        return new PagedResultDto<BookDto>(
            totalCount,
            ObjectMapper.Map<List<Book>, List<BookDto>>(books)
        );
    }

    // No caching on write operations
    [Authorize(AutoCacheDemoPermissions.Books.Create)]
    public async Task<BookDto> CreateAsync(CreateUpdateBookDto input)
    {
        var book = ObjectMapper.Map<CreateUpdateBookDto, Book>(input);
        await _repository.InsertAsync(book); // 👈 This will trigger cache invalidation
        return ObjectMapper.Map<Book, BookDto>(book);
    }
}

What Happens Here:

When GetAsync is called, the interceptor checks the cache
On cache miss, the actual method executes and the result is cached
When CreateAsync inserts a Book, the invalidation handler clears all caches related to Book
Next call to GetAsync will fetch fresh data

Advanced Features

User-Specific Caching

For user-specific data, use AutoCacheScope.CurrentUser:

[Cache(typeof(Order), Scope = AutoCacheScope.CurrentUser)]
public virtual async Task<List<OrderDto>> GetMyOrdersAsync()
{
    var orders = await _orderRepository.GetListAsync(x => x.UserId == CurrentUser.Id);
    return ObjectMapper.Map<List<Order>, List<OrderDto>>(orders);
}

Each user gets their own cache entry, automatically invalidated when their orders change.

Custom Cache Keys

For fine-grained control, add custom cache key segments:

[Cache(
    typeof(Product), 
    Scope = AutoCacheScope.Global,
    AdditionalCacheKey = "featured"
)]
public virtual async Task<List<ProductDto>> GetFeaturedProductsAsync()
{
    // Only featured products are cached separately
    return await GetProductsByCategoryAsync("Featured");
}

Performance Metrics

Monitor cache performance using IAutoCacheMetrics:

public class CacheMonitoringService : ITransientDependency
{
    private readonly IAutoCacheMetrics _metrics;

    public CacheMonitoringService(IAutoCacheMetrics metrics)
    {
        _metrics = metrics;
    }

    public AutoCacheStatistics GetStatistics()
    {
        return _metrics.GetStatistics(); // 👈 Get hit rate, miss count, error count
    }
}

Testing the Application

1. Run the Application

abp new BookStore -u mvc -d ef
cd BookStore
dotnet run --project src/BookStore.Web

2. Test Cache Behavior

Create a simple test to verify caching:

[Fact]
public async Task Should_Cache_Book_Results()
{
    // First call - cache miss
    var book1 = await _bookAppService.GetAsync(testBookId);

    // Second call - cache hit (should be faster)
    var book2 = await _bookAppService.GetAsync(testBookId);

    book1.Name.ShouldBe(book2.Name);
}

[Fact]
public async Task Should_Invalidate_Cache_On_Update()
{
    // Cache the book
    var book1 = await _bookAppService.GetAsync(testBookId);

    // Update the book
    await _bookAppService.UpdateAsync(testBookId, new CreateUpdateBookDto 
    { 
        Name = "Updated Name" 
    });

    // Fetch again - should get updated data (cache was invalidated)
    var book2 = await _bookAppService.GetAsync(testBookId);

    book2.Name.ShouldBe("Updated Name");
}

3. Monitor Cache Performance

Check your application logs for cache metrics:

[INF] Cache Hit: BookAppService:GetAsync:book-id-123 (Response Time: 5ms)
[INF] Cache Miss: BookAppService:GetListAsync (Response Time: 156ms)
[INF] Cache Invalidation: Book entity changed, cleared 3 cache entries

Key Takeaways

✅ Automatic caching reduces boilerplate code - Just add [Cache] attribute to methods instead of manual cache management

✅ Smart invalidation keeps data fresh - Entity changes automatically clear related caches without manual intervention

✅ Multiple scoping options - Support for global, user-specific, authenticated, and entity-level caching strategies

✅ Built-in fallback handling - Gracefully falls back to method execution if caching fails

✅ Performance monitoring - Track cache hits, misses, and errors for optimization

Conclusion

Automatic method-level caching dramatically simplifies performance optimization in ABP Framework applications. By using attributes and interceptors, you can add sophisticated caching behavior without cluttering your business logic with cache management code.

The system we've built provides intelligent cache invalidation, multiple scoping strategies, and built-in monitoring - all while maintaining clean, readable code. Whether you're building a small application or an enterprise system, this approach scales elegantly and integrates seamlessly with ABP's architecture.

Ready to implement this in your project? The complete working implementation is available in the AbpAutoCacheDemo repository. You can clone the repository, explore the code, and even extract the src/AutoCache folder to use it as a standalone library in your own ABP applications. The main implementation commit shows all the components working together, including interceptor registration, cache key management, and automatic invalidation handlers.r you're building a small application or an enterprise system, this approach scales elegantly and integrates seamlessly with ABP's architecture.

Ready to implement this in your project? Check out the complete working example in the repository linked below, and start improving your application's performance today!

References

.NET Conf China 2025: Changing the World, Changing Ourselves - See You Again in Shanghai

ABP.IO — Wed, 03 Dec 2025 08:32:26 +0000

.NET Conf China 2025: Changing the World, Changing Ourselves - See You Again in Shanghai

.NET Conf China 2025 is an annual community event for developers, celebrating the release of .NET 10 (LTS) and the achievements of the past year in China. As an extension of .NET Conf 2025, this event brings together local tech communities, well-known companies, and open-source organizations. It has become the largest .NET online and offline conference in China, dedicated to spreading .NET technology in Chinese and fostering collaboration and exchange.

Event Highlights: Key Topics and Takeaways

This year’s conference focused on three main themes: performance improvements, AI integration, and cross-platform development. Topics covered how to achieve performance gains while maintaining engineering quality, balancing between multi-platform consistency and native capabilities, and taking generative AI from “demo-level” to “production-ready.” On the community and ecosystem side, the event showcased the .NET Foundation’s and domestic and international companies’ progress in supporting architectures like ARM, LoongArch, and RISC-V. It also highlighted best practices in DevOps, observability, and engineering toolchains, creating a complete path from ideas to implementation.

Opening Keynote

Scott Hanselman kicked off .NET Conf China 2025 with a video keynote, announcing that .NET 10 is now available on the official website. He framed the release around four pillars—AI, cloud-native, cross-platform, and performance—including integration with the Microsoft Agent Framework for building and orchestrating multi-agent systems in .NET/C#, industry-leading container and Kubernetes support with .NET Aspire simplifying local containerized development, a richer cross-platform desktop ecosystem (.NET MAUI, Avalonia, Uno Platform), and major performance gains such as Native AOT and single-file publishing for faster startup and easier distribution across platforms.

He underscored China’s importance as .NET’s second-largest market, with roughly 13% of users, and noted that generative AI usage in China has doubled in 2025. The local community is seeing strong momentum around ML.NET, .NET Aspire, and the C# Dev Kit in VS Code. Reflecting on his Baby Smash game written 20 years ago, which now runs cross-platform on .NET 10, he called on developers to modernize: move existing Web, WinForms, and WPF apps to the cloud, improve performance, ship as a single executable, and weave in AI capabilities.

On AI, he emphasized a human-centered stance: AI and agents should augment, not replace, developers. In the future, developers will orchestrate and govern agents, and human judgment will matter more than ever. He closed by thanking the open-source community for its many proposals and pull requests, stressing that .NET is an open-source platform built together by Microsoft and the community, and wishing everyone an inspiring conference and a joyful journey with .NET 10.

Roundtable Discussion

The roundtable discussion, titled “Empowering with AI, Breaking Through Cross-Platform Barriers, and Ecosystem Innovation,” focused on practical implementation. It explored typical paths for large models and intelligent agents in enterprises, key considerations for choosing cross-platform UI frameworks, and the evolution of these frameworks. Panelists discussed questions like: How can AI capabilities be integrated into existing business processes instead of creating an “experimental” pipeline? How should cross-platform solutions be evaluated in terms of performance, ecosystem, and team skillsets? What are the unique opportunities for domestic ecosystems in the global tech landscape? And how can community collaboration help developers quickly adopt best practices? A shared consensus emerged: in the short term, focus on running scenarios; in the long term, return to engineering fundamentals. Both toolchains and methodologies are equally important.

In-Depth Sessions

The afternoon featured four breakout sessions, covering a wide range of topics with deep dives into both foundational technologies and real-world project reviews:

Frontend and Cross-Platform: Focused on the progress of Avalonia, Blazor, and WebAssembly, as well as the integrated experience of .NET Aspire in multi-service applications. Speakers shared insights on reusing core logic between desktop and web, shortening cold start times with incremental compilation and resource trimming, and performance profiling and optimization in WASM scenarios.
AI Agents and Enterprise Adoption: Discussed multi-agent orchestration, the MCP plugin ecosystem, and enterprise data compliance. From common pitfalls of “demo-level” AI to the “five-step method” for moving from POC to production, the session covered use cases like knowledge retrieval, process automation, intelligent customer service, and developer assistants, emphasizing evaluation metrics, prompt engineering, and monitoring governance.
.NET Practices and Engineering: Focused on the latest capabilities and performance practices of EF Core, the boundaries of NativeAOT, automated testing strategies, and observability implementation. Discussions included database migration strategies, caching and concurrency control for hot paths, end-to-end tracing, and structured logging.
Solutions and Case Studies: From Clean Architecture/DDD to AI-powered business evolution, topics included application modernization, SaaS transformation, and edge-cloud collaboration in AIoT. Speakers broke down modular governance, team collaboration, and release strategies for complex systems, putting “delivering value continuously” at the center stage.

ABP Booth Highlights: Showcases, Conversations, and Fun

The story of ABP began with a promise to create a better starting point. From the frustration of “copy-pasting boilerplate code,” we crafted a modular, opinionated framework. We chose open source and community collaboration. We founded Volosoft to turn our vision into reality with professional tools. Today, tens of thousands of developers explore the ABP framework, and thousands of teams rely on the ABP platform to deliver production-grade .NET applications faster and more securely.

At .NET Conf China 2025, we brought our “developer platform built for developers” to every visitor. Our booth demonstrations started with “a production-ready skeleton from the start”: modular layered architecture, built-in authentication and authorization systems, multi-tenancy support, audit logging, and localization—all out of the box. On the frontend and backend, ABP offers diverse options like MVC, Blazor, and Angular, enabling teams to quickly implement solutions on familiar stacks while maintaining flexibility for future evolution. We also showcased how ABP integrates with containerization, CI/CD, and observability, emphasizing “engineering built into the framework, not reinvented by every team.”

Interaction and Prizes: Sharing technology should also be warm and engaging. We hosted a QR code raffle at the booth, with prizes including ABP stickers, the book Mastering ABP Framework, and Bluetooth headphones. Multiple rounds of raffles and group photos made the interactions more memorable. Many developers shared their ABP experiences and plans for improvement right at the booth, and a few impromptu “code walkthroughs” naturally happened. The love and joy for technology were captured in every handshake and discussion.

Looking Ahead: Building the Ecosystem Together

From an open-source journey to a complete development platform for the future, we’ve always believed that developers deserve a better starting point. Around performance, intelligence, and cross-platform capabilities, we will continue investing in engineering, ecosystem collaboration, and best practice sharing. We also welcome more partners to contribute through documentation and examples, share your experiences, and submit your ideas. Together, let’s make “useful infrastructure” more stable, efficient, and business-friendly.

We look forward to exchanging ideas, sharing practices, and building the ecosystem together at the next gathering. Technology meets creativity, and the possibilities are endless. We’re on the road and waiting for you at the next event.

See you next year at .NET Conf China 2026!

ABP Suite：EfCoreRepository Template change DbContext

ABP.IO — Fri, 28 Nov 2025 03:25:41 +0000

在 ABP Suite 專案中，若有多個 DbContext，預設的 Repository Template 可能會判斷錯誤，導致產生到錯誤的 DbContext。作者提供了一個簡單方法：修改 EfCoreRepository Template，強制指定使用正確的 DbContext，以確保穩定性與一致性。

Go to the Post