mirror of https://github.com/abpframework/abp.git
selman koc
1 day ago
committed by
GitHub
GitHub
437 changed files with 20560 additions and 2636 deletions
@ -0,0 +1,581 @@ |
|||
Multi-tenancy sounds simple at first: one application, many customers. In practice, it changes how you design data access, authentication, configuration, monitoring, migrations, and even support workflows. |
|||
|
|||
If you get it right, you can serve many organizations efficiently from one platform. If you get it wrong, you risk the worst kind of bug in SaaS: one tenant seeing another tenant's data. |
|||
|
|||
This article explains how to implement multi-tenancy in a practical way, starting from the core patterns and ending with an ABP-based implementation approach. The goal is not just to define multi-tenancy, but to help you choose the right model and avoid the mistakes that usually show up after launch. |
|||
|
|||
## What multi-tenancy actually means |
|||
|
|||
A tenant is usually a customer organization, company, school, or business unit using your application. Multi-tenancy means multiple tenants use the same application platform while remaining isolated from each other. |
|||
|
|||
That isolation can include: |
|||
|
|||
- Data isolation |
|||
- Authentication and authorization boundaries |
|||
- Feature differences per tenant |
|||
- Performance protection |
|||
- Audit and compliance boundaries |
|||
|
|||
It is useful to separate two ideas that are often mixed up: |
|||
|
|||
- **Multi-tenant application**: one application instance serves many tenants |
|||
- **Multi-instance deployment**: each customer gets a separate deployment |
|||
|
|||
Multi-instance is simpler from an isolation perspective, but more expensive to operate. Multi-tenancy is usually more efficient, but it requires stronger architectural discipline. |
|||
|
|||
## Choose your data isolation model first |
|||
|
|||
Most multi-tenancy decisions become easier once you choose the data isolation model. There are three common patterns. |
|||
|
|||
### 1. Shared database, shared schema |
|||
|
|||
This is the most common starting point. All tenants use the same tables, and each tenant-owned row includes a `TenantId`. |
|||
|
|||
Example: |
|||
|
|||
```sql |
|||
Orders |
|||
- Id |
|||
- TenantId |
|||
- CustomerId |
|||
- TotalAmount |
|||
- CreationTime |
|||
``` |
|||
|
|||
Every query must be tenant-aware. |
|||
|
|||
**Pros** |
|||
|
|||
- Lowest infrastructure cost |
|||
- Simplest provisioning |
|||
- One migration path |
|||
- Fastest way to launch |
|||
|
|||
**Cons** |
|||
|
|||
- Highest risk of accidental data leakage if tenant filtering is missed |
|||
- Noisy neighbor problems are more likely |
|||
- Harder to isolate performance-heavy tenants |
|||
- Compliance requirements may rule it out |
|||
|
|||
**Best for** |
|||
|
|||
- MVPs |
|||
- Early-stage SaaS products |
|||
- Products with many small tenants |
|||
- Teams that want operational simplicity first |
|||
|
|||
### 2. Shared database, separate schema per tenant |
|||
|
|||
In this model, tenants share the same database server, but each tenant has its own schema. |
|||
|
|||
For example: |
|||
|
|||
- `tenant_a.Orders` |
|||
- `tenant_b.Orders` |
|||
|
|||
**Pros** |
|||
|
|||
- Better separation than shared schema |
|||
- Easier tenant-specific backup and restore |
|||
- Lower leakage risk than row-level isolation alone |
|||
|
|||
**Cons** |
|||
|
|||
- Migrations become harder |
|||
- Schema drift becomes a real risk |
|||
- Managing hundreds of schemas gets messy |
|||
- Connection and routing logic becomes more complex |
|||
|
|||
**Best for** |
|||
|
|||
- Moderate compliance needs |
|||
- Tens to a few hundreds of tenants |
|||
- Teams that need more isolation without going full database-per-tenant |
|||
|
|||
### 3. Database per tenant |
|||
|
|||
Each tenant gets its own database, and sometimes even its own server. |
|||
|
|||
**Pros** |
|||
|
|||
- Strongest isolation |
|||
- Easier compliance story |
|||
- Easier tenant-specific backup, restore, and residency rules |
|||
- Better performance isolation |
|||
- Easier to support premium tenants with custom SLAs |
|||
|
|||
**Cons** |
|||
|
|||
- Higher cost |
|||
- More provisioning automation required |
|||
- More complex migrations and monitoring |
|||
- Operational overhead grows quickly |
|||
|
|||
**Best for** |
|||
|
|||
- Enterprise SaaS |
|||
- Regulated industries |
|||
- High-value tenants |
|||
- Cases where data residency or strict isolation matters |
|||
|
|||
## How to choose the right pattern |
|||
|
|||
There is no universally correct model. The right choice depends on trade-offs. |
|||
|
|||
Use these questions to decide: |
|||
|
|||
- How many tenants do you expect in 6 to 24 months? |
|||
- Do you have compliance requirements like HIPAA, GDPR residency constraints, or strict audit demands? |
|||
- How much tenant customization do you need? |
|||
- Can your team operate many databases reliably? |
|||
- What happens if one tenant runs expensive reports all day? |
|||
- Do you need tenant-specific backup and restore? |
|||
|
|||
A practical rule: |
|||
|
|||
- Start with **shared schema** if speed and cost matter most |
|||
- Use **database per tenant** if isolation and compliance matter most |
|||
- Use a **hybrid model** if your tenant base is mixed |
|||
|
|||
A hybrid model is common in real SaaS systems: |
|||
|
|||
- Small tenants live in shared infrastructure |
|||
- Large enterprise tenants get dedicated databases |
|||
|
|||
That gives you a better cost curve without forcing every customer into the most expensive setup. |
|||
|
|||
## The core building blocks of a multi-tenant system |
|||
|
|||
Regardless of the storage model, most implementations need the same building blocks. |
|||
|
|||
### Tenant resolution |
|||
|
|||
Before your application can isolate anything, it must know which tenant the request belongs to. |
|||
|
|||
Common tenant resolution strategies: |
|||
|
|||
- Subdomain: `acme.yourapp.com` |
|||
- Custom domain: `portal.acme.com` |
|||
- Header: `X-Tenant-Id` |
|||
- JWT claim or token metadata |
|||
- URL segment: `/t/acme/orders` |
|||
|
|||
Subdomain-based resolution is usually the cleanest for SaaS products. Header-based resolution is common for internal APIs but easier to misuse if not protected. |
|||
|
|||
The important part is consistency. Resolve the tenant early in the request pipeline and make it available everywhere else. |
|||
|
|||
### Tenant context |
|||
|
|||
Once resolved, store the active tenant in a tenant context that application services, repositories, caches, and logs can access. |
|||
|
|||
Typical tenant context data includes: |
|||
|
|||
- Tenant ID |
|||
- Tenant name or slug |
|||
- Connection string or database mapping |
|||
- Enabled features |
|||
- Region or residency info |
|||
|
|||
### Data filtering |
|||
|
|||
If you use shared tables, tenant filtering must be automatic. Do not rely on developers remembering to add `where TenantId == currentTenantId` in every query. |
|||
|
|||
This is where frameworks matter. ABP helps a lot here because it has built-in multi-tenancy support and data filters for tenant-aware entities. |
|||
|
|||
### Tenant-aware configuration |
|||
|
|||
Sooner or later, tenants will ask for differences: |
|||
|
|||
- Feature A enabled only for premium plans |
|||
- Different email templates |
|||
- Different password policies |
|||
- Different integrations |
|||
- Different branding |
|||
|
|||
Do not solve this with `if (tenant == ...)` scattered across the codebase. |
|||
|
|||
Use: |
|||
|
|||
- Feature flags |
|||
- Tenant settings |
|||
- Edition or plan-based configuration |
|||
- Modular integration points |
|||
|
|||
### Tenant-aware logging and auditing |
|||
|
|||
Every log entry and audit event should include tenant context where possible. |
|||
|
|||
That makes it much easier to answer questions like: |
|||
|
|||
- Which tenant triggered this error? |
|||
- Which tenant is causing high database load? |
|||
- Who accessed this record? |
|||
- Which tenant had failed background jobs? |
|||
|
|||
## Implementing multi-tenancy in ASP.NET Core |
|||
|
|||
If you build multi-tenancy manually in ASP.NET Core, the implementation usually follows this flow: |
|||
|
|||
1. Resolve tenant from the request |
|||
2. Load tenant metadata from a tenant store |
|||
3. Set current tenant context |
|||
4. Route database access based on tenant |
|||
5. Apply tenant filters automatically |
|||
6. Include tenant info in logs, cache keys, and background jobs |
|||
|
|||
A minimal tenant resolver middleware might look like this: |
|||
|
|||
```csharp |
|||
public class TenantResolutionMiddleware |
|||
{ |
|||
private readonly RequestDelegate _next; |
|||
|
|||
public TenantResolutionMiddleware(RequestDelegate next) |
|||
{ |
|||
_next = next; |
|||
} |
|||
|
|||
public async Task InvokeAsync(HttpContext context, ICurrentTenantAccessor tenantAccessor) |
|||
{ |
|||
var host = context.Request.Host.Host; |
|||
var subdomain = host.Split('.').FirstOrDefault(); |
|||
|
|||
if (!string.IsNullOrWhiteSpace(subdomain) && subdomain != "www") |
|||
{ |
|||
tenantAccessor.CurrentTenantId = await ResolveTenantIdAsync(subdomain); |
|||
} |
|||
|
|||
await _next(context); |
|||
} |
|||
|
|||
private Task<Guid?> ResolveTenantIdAsync(string subdomain) |
|||
{ |
|||
return Task.FromResult<Guid?>(null); |
|||
} |
|||
} |
|||
``` |
|||
|
|||
That is only the beginning. The hard part is making the rest of the application consistently tenant-aware. |
|||
|
|||
For example, your repository layer must avoid this kind of bug: |
|||
|
|||
```csharp |
|||
var orders = await _dbContext.Orders |
|||
.Where(x => x.Status == OrderStatus.Pending) |
|||
.ToListAsync(); |
|||
``` |
|||
|
|||
In a shared-schema model, that query is dangerous because it ignores tenant isolation. |
|||
|
|||
Safer approaches include: |
|||
|
|||
- Global query filters |
|||
- Tenant-aware repositories |
|||
- Row-level security at the database level |
|||
- Framework-level multi-tenancy abstractions |
|||
|
|||
## Implementing multi-tenancy with ABP |
|||
|
|||
ABP is a strong fit for multi-tenant business applications because multi-tenancy is built into the framework rather than bolted on later. |
|||
|
|||
ABP gives you several useful pieces out of the box: |
|||
|
|||
- Tenant resolution pipeline |
|||
- `ICurrentTenant` abstraction |
|||
- Multi-tenant entity support via `IMultiTenant` |
|||
- Data filters for tenant isolation |
|||
- Tenant management module |
|||
- Per-tenant connection string support |
|||
- Feature and setting systems |
|||
|
|||
### Tenant-aware entities |
|||
|
|||
In ABP, tenant-owned entities typically implement `IMultiTenant`. |
|||
|
|||
```csharp |
|||
using System; |
|||
using Volo.Abp.MultiTenancy; |
|||
|
|||
public class Product : IMultiTenant |
|||
{ |
|||
public Guid Id { get; set; } |
|||
public Guid? TenantId { get; set; } |
|||
public string Name { get; set; } = string.Empty; |
|||
public decimal Price { get; set; } |
|||
} |
|||
``` |
|||
|
|||
This matters because ABP can automatically apply tenant filters for entities that belong to a tenant. |
|||
|
|||
### Accessing the current tenant |
|||
|
|||
ABP exposes the current tenant through `ICurrentTenant`. |
|||
|
|||
```csharp |
|||
public class ProductAppService : ApplicationService |
|||
{ |
|||
private readonly IRepository<Product, Guid> _productRepository; |
|||
private readonly ICurrentTenant _currentTenant; |
|||
|
|||
public ProductAppService( |
|||
IRepository<Product, Guid> productRepository, |
|||
ICurrentTenant currentTenant) |
|||
{ |
|||
_productRepository = productRepository; |
|||
_currentTenant = currentTenant; |
|||
} |
|||
|
|||
public async Task<List<ProductDto>> GetListAsync() |
|||
{ |
|||
var products = await _productRepository.GetListAsync(); |
|||
return ObjectMapper.Map<List<Product>, List<ProductDto>>(products); |
|||
} |
|||
} |
|||
``` |
|||
|
|||
In a tenant context, ABP automatically scopes the repository query to the current tenant for multi-tenant entities. |
|||
|
|||
That is exactly the kind of default you want in a multi-tenant system: safe behavior unless you intentionally opt out. |
|||
|
|||
### Switching tenant context |
|||
|
|||
Background jobs, admin tools, and migration workflows sometimes need to operate in a specific tenant context. |
|||
|
|||
ABP supports this with `ICurrentTenant.Change(...)`. |
|||
|
|||
```csharp |
|||
using (_currentTenant.Change(tenantId)) |
|||
{ |
|||
var count = await _productRepository.GetCountAsync(); |
|||
} |
|||
``` |
|||
|
|||
This is useful, but it should be used carefully. Tenant context switching is powerful and easy to abuse if you do not keep boundaries clear. |
|||
|
|||
### Per-tenant connection strings |
|||
|
|||
If you choose database-per-tenant, ABP supports tenant-specific connection strings. That lets you keep the same application code while routing different tenants to different databases. |
|||
|
|||
This is one of the biggest practical advantages of using ABP for multi-tenancy: you can start simple and evolve toward stronger isolation without rewriting your entire application model. |
|||
|
|||
## Shared schema vs database per tenant in ABP |
|||
|
|||
ABP supports both host and tenant concepts, which makes it flexible enough for different SaaS stages. |
|||
|
|||
### Shared schema with ABP |
|||
|
|||
This is usually the easiest starting point. |
|||
|
|||
Use it when: |
|||
|
|||
- You want fast delivery |
|||
- Your tenants are relatively small |
|||
- Compliance requirements are moderate |
|||
- Your team wants simpler operations |
|||
|
|||
What to watch: |
|||
|
|||
- Ensure all tenant-owned entities implement `IMultiTenant` |
|||
- Be careful with raw SQL and custom queries |
|||
- Include `TenantId` in indexes where needed |
|||
- Test cross-tenant isolation aggressively |
|||
|
|||
### Database per tenant with ABP |
|||
|
|||
Use it when: |
|||
|
|||
- You need stronger isolation |
|||
- You have enterprise customers |
|||
- You need tenant-specific restore or residency |
|||
- You expect some tenants to be much larger than others |
|||
|
|||
What to watch: |
|||
|
|||
- Automate provisioning |
|||
- Automate migrations across tenant databases |
|||
- Monitor connection usage and migration failures |
|||
- Keep tenant metadata accurate and centralized |
|||
|
|||
## Migrations and schema management |
|||
|
|||
This is where many multi-tenant systems become painful. |
|||
|
|||
With shared schema, migrations are straightforward: apply once. |
|||
|
|||
With schema-per-tenant or database-per-tenant, you need orchestration. |
|||
|
|||
A practical migration workflow includes: |
|||
|
|||
- Track tenant inventory centrally |
|||
- Apply migrations in batches |
|||
- Record migration status per tenant |
|||
- Retry safely on failure |
|||
- Alert on drift |
|||
- Avoid manual one-off fixes unless documented and automated later |
|||
|
|||
If you have 5 tenants, manual migration might feel acceptable. If you have 500, it becomes an operational risk. |
|||
|
|||
For ABP-based systems, treat tenant database migration as a first-class operational workflow, not an afterthought. |
|||
|
|||
## Security pitfalls to avoid |
|||
|
|||
Multi-tenancy failures are usually not caused by the concept itself. They are caused by inconsistent enforcement. |
|||
|
|||
The most common mistakes are: |
|||
|
|||
### 1. Missing tenant filters |
|||
|
|||
This is the classic bug. One query forgets tenant scoping, and data leaks. |
|||
|
|||
Reduce the risk with: |
|||
|
|||
- Framework-level filters |
|||
- Repository abstractions |
|||
- Database row-level security where appropriate |
|||
- Integration tests that verify isolation |
|||
|
|||
### 2. Unsafe admin features |
|||
|
|||
Support tools, exports, reporting endpoints, and background jobs often bypass normal application flows. That makes them common leakage points. |
|||
|
|||
Treat admin code as high-risk code. |
|||
|
|||
### 3. Tenant context lost in async or background processing |
|||
|
|||
If a background job processes tenant data, it must explicitly carry tenant context. |
|||
|
|||
Do not assume the request context still exists. |
|||
|
|||
### 4. Shared cache keys |
|||
|
|||
If your cache key is just `product-list`, you already have a bug. |
|||
|
|||
Use tenant-aware cache keys such as: |
|||
|
|||
```text |
|||
tenant:{tenantId}:product-list |
|||
``` |
|||
|
|||
### 5. Weak audit trails |
|||
|
|||
When something goes wrong, you need to know: |
|||
|
|||
- Which tenant was affected |
|||
- Which user triggered the action |
|||
- Which service handled it |
|||
- Which data store was involved |
|||
|
|||
Without tenant-aware auditing, incident response becomes much harder. |
|||
|
|||
## Performance and noisy neighbor control |
|||
|
|||
Shared infrastructure saves money, but it also creates contention. |
|||
|
|||
A single tenant can hurt others through: |
|||
|
|||
- Expensive reports |
|||
- Large imports |
|||
- Chatty integrations |
|||
- Poorly indexed queries |
|||
- Background jobs running at the wrong time |
|||
|
|||
Mitigations include: |
|||
|
|||
- Indexing by `TenantId` |
|||
- Query timeouts |
|||
- Rate limiting per tenant |
|||
- Queue isolation for heavy jobs |
|||
- Read replicas for reporting |
|||
- Partitioning large tables |
|||
- Moving heavy tenants to dedicated databases |
|||
|
|||
This is why hybrid multi-tenancy is so common. It gives you an escape hatch when one tenant outgrows the shared model. |
|||
|
|||
## A practical implementation plan |
|||
|
|||
If you are building a new SaaS product, this is a sensible rollout path. |
|||
|
|||
### Phase 1: Start with shared schema |
|||
|
|||
- Resolve tenant from subdomain or domain |
|||
- Store tenant metadata centrally |
|||
- Use framework-level tenant filters |
|||
- Make all tenant-owned entities explicit |
|||
- Add tenant-aware logging, caching, and auditing |
|||
|
|||
For ABP, this is usually the fastest path because the framework already supports the core abstractions. |
|||
|
|||
### Phase 2: Add tenant configuration and feature management |
|||
|
|||
- Per-tenant settings |
|||
- Feature flags |
|||
- Plan-based capabilities |
|||
- Branding and integration settings |
|||
|
|||
This keeps customization manageable without branching the codebase. |
|||
|
|||
### Phase 3: Prepare for tenant mobility |
|||
|
|||
Even if you start with shared schema, design for future migration. |
|||
|
|||
That means: |
|||
|
|||
- Stable tenant IDs |
|||
- Export/import or replication strategy |
|||
- Clear ownership boundaries in data |
|||
- No hidden cross-tenant joins |
|||
|
|||
### Phase 4: Move selected tenants to dedicated databases |
|||
|
|||
Use an expand-backfill-contract approach: |
|||
|
|||
- **Expand**: create the target database |
|||
- **Backfill**: copy tenant data |
|||
- **Dual-write**: temporarily write to both stores if needed |
|||
- **Contract**: switch traffic and retire the old location |
|||
|
|||
This is much safer than a big-bang migration. |
|||
|
|||
## When to use multi-tenancy and when not to |
|||
|
|||
### When to use multi-tenancy |
|||
|
|||
- You are building a SaaS platform for many organizations |
|||
- Tenants share most application behavior |
|||
- Operational efficiency matters |
|||
- You want centralized upgrades and deployment |
|||
- You need a scalable commercial model |
|||
|
|||
### When NOT to use multi-tenancy |
|||
|
|||
- Every customer needs deep infrastructure-level customization |
|||
- Compliance requires strict physical isolation from day one |
|||
- Your team cannot support the operational complexity safely |
|||
- You only have a few large customers and each behaves like a separate product |
|||
|
|||
In those cases, multi-instance deployment may be the better choice. |
|||
|
|||
## Final recommendations |
|||
|
|||
If you are unsure where to start, start simpler than you think, but not sloppier than you can afford. |
|||
|
|||
That usually means: |
|||
|
|||
- Shared schema first |
|||
- Strong tenant resolution |
|||
- Automatic tenant filtering |
|||
- Tenant-aware logs, cache, and jobs |
|||
- A migration path to dedicated databases later |
|||
|
|||
ABP is especially useful here because it gives you the right primitives early: current tenant context, tenant-aware entities, filters, settings, and connection string support. That reduces the amount of custom plumbing you need to build and maintain. |
|||
|
|||
The biggest mistake is not choosing the wrong pattern. It is choosing a pattern without planning how tenant isolation will be enforced everywhere. |
|||
|
|||
## TL;DR |
|||
|
|||
- Multi-tenancy is mostly about safe isolation of data, behavior, and operations across customers. |
|||
- Shared schema is the easiest starting point; database-per-tenant gives the strongest isolation but adds operational cost. |
|||
- In ASP.NET Core, tenant resolution, tenant context, automatic filtering, and tenant-aware caching/logging are essential. |
|||
- ABP makes multi-tenancy easier with `ICurrentTenant`, `IMultiTenant`, data filters, tenant management, and per-tenant connection strings. |
|||
- Design for evolution early so large tenants can move to dedicated databases without a painful rewrite. |
|||
|
After Width: | Height: | Size: 2.0 MiB |
|
After Width: | Height: | Size: 1.0 MiB |
|
After Width: | Height: | Size: 897 KiB |
|
After Width: | Height: | Size: 946 KiB |
File diff suppressed because it is too large
|
After Width: | Height: | Size: 2.2 MiB |
|
After Width: | Height: | Size: 960 KiB |
|
After Width: | Height: | Size: 855 KiB |
|
After Width: | Height: | Size: 1.0 MiB |
|
After Width: | Height: | Size: 1.1 MiB |
File diff suppressed because it is too large
|
After Width: | Height: | Size: 1.8 MiB |
|
After Width: | Height: | Size: 1.1 MiB |
|
After Width: | Height: | Size: 995 KiB |
|
After Width: | Height: | Size: 926 KiB |
|
After Width: | Height: | Size: 999 KiB |
|
After Width: | Height: | Size: 74 KiB |
|
After Width: | Height: | Size: 103 KiB |
|
After Width: | Height: | Size: 24 KiB |
|
After Width: | Height: | Size: 12 KiB |
|
After Width: | Height: | Size: 40 KiB |
@ -0,0 +1,116 @@ |
|||
# ABP Studio Is Now Available on Linux |
|||
|
|||
We are excited to announce that [ABP Studio](https://abp.io/studio), our cross-platform desktop application for ABP developers, is now available on Linux. |
|||
|
|||
With this release, Linux users can download and run ABP Studio as an **x64 AppImage**. This is an important step in making ABP Studio available wherever .NET and ABP developers prefer to work. |
|||
|
|||
## What can you do with ABP Studio? |
|||
|
|||
[ABP Studio](https://abp.io/studio) is a desktop application designed to make ABP development faster, easier, and more comfortable. It offers: |
|||
|
|||
* Easy creation of new solutions, from simple applications to distributed systems |
|||
* Visual architecture management for modular monolith and microservice solutions |
|||
* Solution exploration tools for entities, services, packages, and HTTP APIs |
|||
* Simplified running, debugging, and monitoring of multi-application solutions |
|||
* Kubernetes integration capabilities |
|||
* Built-in access to ABP-specific tooling and workflows |
|||
|
|||
The screenshots below were captured from ABP Studio on Linux through the AppImage. |
|||
|
|||
 |
|||
|
|||
 |
|||
|
|||
## Linux Support Has Arrived |
|||
|
|||
ABP Studio has already been supporting multiple desktop environments, and now Linux joins that list. |
|||
|
|||
You can currently use ABP Studio on: |
|||
|
|||
* Windows x64 |
|||
* Windows ARM |
|||
* macOS Apple Silicon |
|||
* macOS Intel |
|||
* Linux x64 **(New!)** |
|||
|
|||
On Linux, the current distribution format is **AppImage**, which provides a practical way to distribute a desktop application across different Linux distributions without requiring a distribution-specific installer package. |
|||
|
|||
## What This Means for Developers |
|||
|
|||
Many ABP developers use Linux as their daily development environment. Until now, they needed to switch to another operating system to use ABP Studio. With Linux support, developers can now stay on their preferred platform and still benefit from ABP Studio's solution creation, architecture design, solution runner, monitoring, and integrated development experience. |
|||
|
|||
This is especially valuable for teams that already build and run their backend services on Linux-based environments and want to keep their development workflow aligned with that ecosystem. |
|||
|
|||
## AI Agent Is Available on Linux Too |
|||
|
|||
Another common question from the community has been whether ABP Studio AI Agent can be used on Linux machines. With this release, the answer is yes. |
|||
|
|||
Linux users can now use ABP Studio AI Agent in their own development environment. You can ask questions about your solution, plan implementation steps before changing code, and let the agent help with coding tasks while ABP Studio understands your ABP solution structure, build flow, and runtime context. |
|||
|
|||
 |
|||
For a deeper look at the AI Agent experience, see the original announcement: [Introducing ABP Studio AI Agent](https://abp.io/community/announcements/introducing-abp-studio-ai-agent-o1ni0toc). |
|||
|
|||
## Getting Started |
|||
|
|||
Downloading and running ABP Studio on Linux is simple: |
|||
|
|||
 |
|||
|
|||
1. Go to [abp.io/studio](https://abp.io/studio) |
|||
2. Download the **Linux x64 AppImage** |
|||
3. Open a terminal in the folder where the file was downloaded |
|||
4. Make the AppImage executable and run it |
|||
|
|||
```bash |
|||
chmod +x ./AbpStudio-stable.AppImage |
|||
./AbpStudio-stable.AppImage |
|||
``` |
|||
|
|||
Once launched, you can start using ABP Studio just like on the other supported platforms. |
|||
|
|||
## If the AppImage Does Not Run Directly |
|||
|
|||
Some Linux distributions may require additional runtime support for direct AppImage execution. |
|||
|
|||
For example, on some Ubuntu and Debian-based systems, you may need `libfuse2`: |
|||
|
|||
```bash |
|||
sudo apt update |
|||
sudo apt install libfuse2 |
|||
``` |
|||
|
|||
If FUSE is not available on your machine, you can still extract and run the AppImage manually: |
|||
|
|||
```bash |
|||
./AbpStudio-stable.AppImage --appimage-extract |
|||
./squashfs-root/AppRun |
|||
``` |
|||
|
|||
This fallback can be useful for testing or for environments where AppImage mounting is restricted. |
|||
|
|||
## Current Scope and Limitations |
|||
|
|||
This first Linux release is intentionally focused so we can deliver a reliable experience quickly. |
|||
|
|||
Here is the current scope: |
|||
|
|||
* Linux distribution is currently provided as an **x64 AppImage** |
|||
* **Linux ARM builds are not published yet** |
|||
* Depending on your Linux distribution, some native desktop or browser-related libraries may need to be installed |
|||
* When ABP Studio can detect a known native dependency problem, it tries to show guidance in the UI instead of leaving you with an unclear failure |
|||
|
|||
This means Linux support is ready to use today, and we will continue to improve the Linux experience in future releases. |
|||
|
|||
## A Better Cross-Platform Experience |
|||
|
|||
ABP Studio has always aimed to be the default way to start and develop ABP solutions. Linux support brings us closer to that goal by making the Studio experience more accessible across major desktop platforms. |
|||
|
|||
Whether you are creating a new solution, exploring packages and services, running multiple applications together, or monitoring runtime behavior, you can now do that on Linux too. |
|||
|
|||
## Conclusion |
|||
|
|||
We are happy to finally make ABP Studio available on Linux. |
|||
|
|||
This first release focuses on a practical and reliable target: **Linux x64 through AppImage**. It already opens the door for many developers who prefer Linux as their primary development environment, and it gives us a strong foundation to improve the Linux experience further. |
|||
|
|||
Please download it, try it in your daily workflow, and share your feedback with us. If you encounter a problem or want to request additional Linux targets like ARM, feel free to open an issue and let us know. |
|||
@ -0,0 +1,496 @@ |
|||
ABP has supported multiple UI approaches for a long time, but many teams building line-of-business apps have been waiting for a first-class React option that feels native to the framework instead of bolted on. That is exactly what the ABP React template brings. |
|||
|
|||
If you are already using ABP for application services, modules, authentication, multi-tenancy, and code generation, the React template gives you a modern frontend stack without forcing you to hand-wire the same infrastructure in every project. You get React + TypeScript, a sensible project structure, generated API clients, authentication, localization, permission-aware UI, and a prebuilt admin experience that matches how ABP applications are typically built. |
|||
|
|||
This article explains what the ABP React template is, how it is structured, what you get out of the box, where it fits well, and what to watch for before adopting it. |
|||
|
|||
## What is the ABP React template? |
|||
|
|||
The ABP React template is the React UI option in ABP Framework's modern template system. It is available through ABP Studio v3.0+ and through the CLI when you create a modern solution. |
|||
|
|||
Typical commands look like this: |
|||
|
|||
```bash |
|||
abp new MyCompany.MyApp --modern --ui-framework react |
|||
``` |
|||
|
|||
Depending on your architecture, ABP supports React in these template types: |
|||
|
|||
- Layered: `app --modern` |
|||
- Single-layer: `app-nolayers --modern` |
|||
- Microservice: `microservice --modern` |
|||
|
|||
A very important detail: React UI is part of the modern template system. If you create a classic ABP solution, React UI is not included. |
|||
|
|||
At the time of its introduction, the React UI arrived as a beta/preview in 10.4.0-rc.1, with general availability planned for ABP 10.4 stable. So if you are evaluating it, make sure your ABP version and tooling align with the current docs. |
|||
|
|||
## The tech stack behind the template |
|||
|
|||
ABP did not build the React template around random choices. The stack is opinionated, but in a practical way that fits business applications. |
|||
|
|||
### Core frontend stack |
|||
|
|||
The template uses: |
|||
|
|||
- React |
|||
- TypeScript |
|||
- Vite |
|||
- TanStack Router |
|||
- TanStack Query |
|||
- Tailwind CSS |
|||
- shadcn/ui |
|||
- Radix UI |
|||
- Zod |
|||
- React Hook Form |
|||
- Axios |
|||
- Vitest |
|||
|
|||
That combination matters because it covers the common pain points in enterprise React apps: |
|||
|
|||
- Routing is structured and type-friendly. |
|||
- Server state is handled properly instead of scattered across components. |
|||
- Forms and validation are consistent. |
|||
- UI components are source-owned, not black-box widgets. |
|||
- Build and local development are fast. |
|||
|
|||
### Why this stack makes sense for ABP apps |
|||
|
|||
ABP applications usually have: |
|||
|
|||
- many CRUD screens |
|||
- authenticated users |
|||
- role and permission checks |
|||
- localization |
|||
- backend-driven DTOs |
|||
- modular features |
|||
- admin pages |
|||
- multi-tenant concerns |
|||
|
|||
The React template maps well to that reality. It is not trying to be a blank React starter. It is trying to be a production-ready frontend foundation for ABP-based applications. |
|||
|
|||
|
|||
|
|||
 |
|||
|
|||
## Project structure and template layout |
|||
|
|||
The structure depends on which ABP solution type you choose. |
|||
|
|||
### Layered and single-layer solutions |
|||
|
|||
In layered and single-layer templates, the React application lives under the solution root: |
|||
|
|||
```text |
|||
react/ |
|||
``` |
|||
|
|||
The Admin Console is embedded under the backend host and served from: |
|||
|
|||
```text |
|||
/admin-console/* |
|||
``` |
|||
|
|||
This setup is convenient when you want a unified application host and do not need to split the frontend into separate deployable apps. |
|||
|
|||
### Microservice solutions |
|||
|
|||
In the microservice template, the React application is placed under: |
|||
|
|||
```text |
|||
apps/react/ |
|||
``` |
|||
|
|||
The Admin Console is a separate app: |
|||
|
|||
```text |
|||
apps/react-admin-console/ |
|||
``` |
|||
|
|||
It is typically served through the Web Gateway using YARP. This is a better fit when your architecture already separates concerns across gateways and independently deployed services. |
|||
|
|||
### Common folders you will work with |
|||
|
|||
The frontend typically includes folders like these: |
|||
|
|||
- `components/` for layouts, reusable UI, and feature components |
|||
- `lib/` for auth, API setup, theme, and routing helpers |
|||
- `pages/` for page-level components |
|||
- `routes/` for route definitions |
|||
- `locales/` for translations |
|||
|
|||
This is a familiar structure for React teams, but it also reflects ABP conventions well enough that backend and frontend concerns stay aligned. |
|||
|
|||
## What you get out of the box |
|||
|
|||
The main value of the ABP React template is not that it uses React. Plenty of templates do that. The real value is that it wires React into ABP's application model. |
|||
|
|||
|
|||
|
|||
 |
|||
|
|||
## Authentication and authorization |
|||
|
|||
Authentication is one of the first places where many custom React frontends get messy. The ABP React template handles this using OpenID Connect with Authorization Code flow and PKCE against the ABP Auth Server. |
|||
|
|||
That means you get a setup suitable for modern browser-based applications without having to build the auth plumbing from scratch. |
|||
|
|||
### What is included |
|||
|
|||
Out of the box, you get: |
|||
|
|||
- OIDC integration |
|||
- route protection |
|||
- auth-related helpers and hooks |
|||
- support for ABP's authorization model |
|||
- permission-aware navigation and UI |
|||
|
|||
Permission-aware UI is especially useful in real applications. Instead of hardcoding role checks everywhere, you can use ABP's permission system in the frontend so menus, buttons, and screens reflect what the current user is actually allowed to do. |
|||
|
|||
For example, a user without the right permission should not see management actions just because the page rendered successfully. |
|||
|
|||
### Why this matters in practice |
|||
|
|||
In many projects, teams secure the backend correctly but forget to make the frontend behave consistently. The result is confusing UX: |
|||
|
|||
- users see actions they cannot execute |
|||
- menus show modules they cannot access |
|||
- pages fail after navigation instead of being guarded earlier |
|||
|
|||
The ABP React template reduces that mismatch. |
|||
|
|||
## API integration without hand-written client boilerplate |
|||
|
|||
One of the most useful parts of the template is the generated API client approach. |
|||
|
|||
ABP can generate frontend API clients from OpenAPI definitions, so your React app consumes backend endpoints using generated contracts instead of duplicated DTO definitions or hand-written fetch code. |
|||
|
|||
### Why this is a big deal |
|||
|
|||
Without generated clients, frontend/backend integration often drifts over time: |
|||
|
|||
- DTOs change but frontend types do not |
|||
- query strings are built inconsistently |
|||
- error handling varies by developer |
|||
- service layers become repetitive |
|||
|
|||
With the ABP React template, Axios is already set up and typically used together with TanStack Query. That gives you a cleaner pattern for data fetching, caching, invalidation, and loading states. |
|||
|
|||
A simplified example looks like this: |
|||
|
|||
```tsx |
|||
import { useQuery } from '@tanstack/react-query'; |
|||
import { identityUserControllerGetList } from '@/client'; |
|||
|
|||
export function UsersPage() { |
|||
const query = useQuery({ |
|||
queryKey: ['users'], |
|||
queryFn: () => identityUserControllerGetList({ maxResultCount: 10, skipCount: 0 }), |
|||
}); |
|||
|
|||
if (query.isLoading) return <div>Loading...</div>; |
|||
if (query.isError) return <div>Failed to load users.</div>; |
|||
|
|||
return ( |
|||
<ul> |
|||
{query.data.items.map((user) => ( |
|||
<li key={user.id}>{user.userName}</li> |
|||
))} |
|||
</ul> |
|||
); |
|||
} |
|||
``` |
|||
|
|||
The exact generated function names may vary based on your solution, but the pattern is the point: use generated contracts, wrap them with TanStack Query, and keep components focused on UI. |
|||
|
|||
## UI system and customization model |
|||
|
|||
The ABP React template uses shadcn/ui with Radix UI primitives and Tailwind CSS. That is a smart choice for teams that want control over their UI instead of being locked into a vendor component library. |
|||
|
|||
### Source-owned components |
|||
|
|||
This is one of the most important characteristics of the template: the frontend is source-owned. |
|||
|
|||
Your components, pages, and UI primitives live in your solution. They are not hidden behind proprietary packages that you cannot meaningfully adjust. |
|||
|
|||
That gives you freedom to: |
|||
|
|||
- restyle components |
|||
- change layouts |
|||
- modify route structure |
|||
- reorganize menus |
|||
- build your own design language on top |
|||
- customize page composition without fighting framework internals |
|||
|
|||
In practice, ABP places UI primitives under locations like `src/components/ui/`, so you can modify them directly when needed. |
|||
|
|||
### Theme support |
|||
|
|||
The template supports light, dark, and system themes. Styling is based on Tailwind CSS and CSS variables, which is a good fit for maintainable theming. |
|||
|
|||
If your team needs brand-level customization, this approach is usually easier to work with than overriding a large third-party theme package. |
|||
|
|||
### A practical trade-off |
|||
|
|||
Source-owned UI gives you control, but it also means you own consistency. If every developer changes shared components casually, the design system can drift quickly. |
|||
|
|||
The template gives you freedom. Your team still needs discipline. |
|||
|
|||
|
|||
|
|||
 |
|||
|
|||
## Forms, validation, and developer ergonomics |
|||
|
|||
Business apps live and die by form quality. The ABP React template uses React Hook Form and Zod, which is a solid setup for forms that need validation, predictable behavior, and clean code. |
|||
|
|||
This stack helps with: |
|||
|
|||
- schema-driven validation |
|||
- reusable form components |
|||
- clearer error handling |
|||
- less form boilerplate |
|||
- better TypeScript integration |
|||
|
|||
For ABP-style applications with lots of create/update dialogs and data-entry screens, that is a practical choice. |
|||
|
|||
A minimal example might look like this: |
|||
|
|||
```tsx |
|||
import { z } from 'zod'; |
|||
import { useForm } from 'react-hook-form'; |
|||
import { zodResolver } from '@hookform/resolvers/zod'; |
|||
|
|||
const schema = z.object({ |
|||
name: z.string().min(1, 'Name is required'), |
|||
}); |
|||
|
|||
type FormValues = z.infer<typeof schema>; |
|||
|
|||
export function ProductForm() { |
|||
const form = useForm<FormValues>({ |
|||
resolver: zodResolver(schema), |
|||
defaultValues: { name: '' }, |
|||
}); |
|||
|
|||
const onSubmit = (values: FormValues) => { |
|||
console.log(values); |
|||
}; |
|||
|
|||
return ( |
|||
<form onSubmit={form.handleSubmit(onSubmit)}> |
|||
<input {...form.register('name')} /> |
|||
<p>{form.formState.errors.name?.message}</p> |
|||
<button type="submit">Save</button> |
|||
</form> |
|||
); |
|||
} |
|||
``` |
|||
|
|||
The exact ABP project will likely wrap inputs with shared UI components, but the workflow remains familiar. |
|||
|
|||
## Localization and multi-tenancy |
|||
|
|||
If you are building a SaaS product or an internal enterprise application for multiple regions, this part matters a lot. |
|||
|
|||
The ABP React template includes support for: |
|||
|
|||
- localization with i18next |
|||
- ABP localization resources and keys |
|||
- culture information from the backend |
|||
- end-to-end multi-tenant scenarios |
|||
|
|||
This is where ABP has always been strong, and the React template carries that strength into the frontend. |
|||
|
|||
### Why this matters |
|||
|
|||
Many React starters look great until you need to answer these questions: |
|||
|
|||
- Where does the current tenant come from? |
|||
- How does the frontend know which culture is active? |
|||
- How are permission and tenant context propagated to API requests? |
|||
- How do I keep localization aligned with backend resources? |
|||
|
|||
With the ABP React template, these are not afterthoughts. |
|||
|
|||
|
|||
|
|||
 |
|||
|
|||
## The built-in Admin Console |
|||
|
|||
Another notable piece is the React-based Admin Console provided through `Volo.Abp.AdminConsole`. |
|||
|
|||
This gives you a prebuilt admin UI for common ABP modules such as: |
|||
|
|||
- Identity |
|||
- Settings |
|||
- Audit Logs |
|||
- and other standard management features |
|||
|
|||
### Why it is useful |
|||
|
|||
For many projects, admin screens are necessary but not differentiating. You need them, but you do not want to spend weeks rebuilding infrastructure screens that ABP already understands well. |
|||
|
|||
The Admin Console helps you start with a solid baseline. |
|||
|
|||
### One thing to be clear about |
|||
|
|||
The Admin Console is managed by ABP and is often intended to be used mostly as-is. If your project requires heavy customization there, you should evaluate that path carefully before assuming it behaves like the rest of your source-owned frontend. |
|||
|
|||
That is not necessarily a problem, but it is worth knowing early. |
|||
|
|||
## Runtime configuration with dynamic-env.json |
|||
|
|||
A practical detail that deserves more attention is `dynamic-env.json` under the public folder. |
|||
|
|||
This file allows runtime configuration for values such as: |
|||
|
|||
- OAuth issuer |
|||
- client ID |
|||
- API base URLs |
|||
- related environment settings |
|||
|
|||
That means you can adapt environment-specific settings without rebuilding the frontend for every deployment target. |
|||
|
|||
For teams deploying across dev, staging, and production, this is much more convenient than baking every environment value into the build. |
|||
|
|||
### Real-world example |
|||
|
|||
Suppose your staging environment uses different hostnames and an alternate auth server URL. With runtime configuration, you can update those values at deployment time instead of producing another frontend artifact just for staging. |
|||
|
|||
That said, when you change URLs or hostnames, remember that runtime config is only part of the story. You also need to update OpenIddict client settings such as redirect URIs and related auth configuration. |
|||
|
|||
## Development workflow |
|||
|
|||
The local development loop is straightforward. |
|||
|
|||
### Running the application |
|||
|
|||
You typically: |
|||
|
|||
1. start the backend host with `dotnet run` |
|||
2. go to the React app folder |
|||
3. install dependencies with `npm install` |
|||
4. start the frontend with `npm run dev` |
|||
|
|||
Vite keeps frontend startup and rebuild times fast, which helps a lot when you are iterating on pages and forms. |
|||
|
|||
### Production build |
|||
|
|||
For production, you build the frontend with: |
|||
|
|||
```bash |
|||
npm run build |
|||
``` |
|||
|
|||
This outputs the app to `dist/`. How it is served depends on the template: |
|||
|
|||
- via the backend host in simpler solution structures |
|||
- via a gateway or separate frontend host in microservice setups |
|||
|
|||
### Testing |
|||
|
|||
The template uses Vitest and React Testing Library, with scripts such as: |
|||
|
|||
- `npm run test` |
|||
- `npm run test:coverage` |
|||
|
|||
This is a good baseline. It encourages teams to test UI behavior without dragging in slow or outdated frontend test setups. |
|||
|
|||
## When to use the ABP React template |
|||
|
|||
The ABP React template is a strong fit when your project already wants ABP's backend capabilities and your team prefers React on the frontend. |
|||
|
|||
Use it when: |
|||
|
|||
- you are starting a new ABP project with a modern template |
|||
- you want React + TypeScript with ABP conventions already wired in |
|||
- you need authentication, permissions, localization, and multi-tenancy from day one |
|||
- you want generated API clients instead of duplicated DTOs |
|||
- you prefer source-owned UI components |
|||
- your app is admin-heavy, form-heavy, or module-heavy |
|||
|
|||
### Good fit examples |
|||
|
|||
- SaaS admin portals |
|||
- internal enterprise dashboards |
|||
- operations and management systems |
|||
- modular business applications with many CRUD workflows |
|||
- ABP-based platforms needing a modern React frontend |
|||
|
|||
## When not to use it |
|||
|
|||
It is not the right default for every case. |
|||
|
|||
Avoid or reconsider it when: |
|||
|
|||
- you are on a classic ABP template and do not want to migrate to modern templates |
|||
- your team wants a very custom frontend architecture unrelated to ABP conventions |
|||
- your application is mostly marketing pages or content-driven public pages |
|||
- you do not need ABP's auth, permission, module, or tenant model |
|||
- you expect deep customization of every built-in admin experience without validating the boundaries first |
|||
|
|||
### A practical warning |
|||
|
|||
Do not choose the template just because it uses React. Choose it because you want React inside the ABP ecosystem. |
|||
|
|||
That distinction matters. |
|||
|
|||
## Common pitfalls and things to check early |
|||
|
|||
The template is productive, but there are a few details worth validating at the beginning of a project. |
|||
|
|||
### 1. Make sure you are using a modern template |
|||
|
|||
This is the most common source of confusion. React UI is for modern templates. If you create a classic solution, the React UI option is not there. |
|||
|
|||
### 2. Align auth settings across environments |
|||
|
|||
If you change frontend URLs, callback paths, ports, or hostnames, update: |
|||
|
|||
- runtime frontend configuration |
|||
- OpenIddict client redirect URIs |
|||
- post-logout redirect URIs if applicable |
|||
- any gateway or proxy configuration involved |
|||
|
|||
A lot of login issues come from partial updates here. |
|||
|
|||
### 3. Treat source-owned UI like a product asset |
|||
|
|||
Because the UI code is in your solution, it is easy to modify. That is good. It also means teams can slowly lose consistency unless they define clear frontend standards. |
|||
|
|||
### 4. Understand the Admin Console boundary |
|||
|
|||
The Admin Console is valuable, but it is not the same customization surface as your app pages. If extensive admin customization is a requirement, validate that path before committing architecture decisions around it. |
|||
|
|||
## Why the ABP React template is different from a plain React starter |
|||
|
|||
A plain React starter gives you flexibility, but also leaves many critical concerns unresolved. The ABP React template starts from a different assumption: most business applications need the same infrastructure pieces, and those pieces should work together. |
|||
|
|||
Compared to a generic starter, ABP gives you tighter integration for: |
|||
|
|||
- auth and authorization |
|||
- generated API clients |
|||
- localization |
|||
- tenant-aware applications |
|||
- modular backend alignment |
|||
- admin capabilities |
|||
- solution-level conventions |
|||
|
|||
That makes it less minimal than a blank React scaffold, but much more useful for real ABP projects. |
|||
|
|||
## Final thoughts |
|||
|
|||
The ABP React template is not interesting because it says React on the label. It is interesting because it brings React into ABP's application model in a way that feels intentional. |
|||
|
|||
You get a modern frontend stack, source-owned customization, generated client integration, and the ABP features many teams actually need in production: permissions, localization, multi-tenancy, and admin tooling. |
|||
|
|||
If your team already values ABP on the backend and wants React on the frontend, this template is one of the fastest ways to get to a serious foundation without spending the first sprint rebuilding plumbing. |
|||
|
|||
## TL;DR |
|||
|
|||
- The ABP React template is available in ABP's modern template system, not classic templates. |
|||
- It uses a practical stack: React, TypeScript, Vite, TanStack Router/Query, shadcn/ui, Tailwind, Zod, and Axios. |
|||
- Key strengths are generated API clients, OIDC auth, permission-aware UI, localization, and multi-tenancy. |
|||
- The frontend is source-owned, which gives you flexibility but also requires discipline. |
|||
- It is a strong choice for ABP-based business apps, especially admin-heavy and SaaS-style applications. |
|||
|
After Width: | Height: | Size: 1.9 MiB |
|
After Width: | Height: | Size: 957 KiB |
|
After Width: | Height: | Size: 933 KiB |
|
After Width: | Height: | Size: 1.0 MiB |
|
After Width: | Height: | Size: 1.0 MiB |
File diff suppressed because it is too large
|
After Width: | Height: | Size: 1.4 MiB |
|
After Width: | Height: | Size: 996 KiB |
|
After Width: | Height: | Size: 861 KiB |
|
After Width: | Height: | Size: 1.0 MiB |
|
After Width: | Height: | Size: 4.5 KiB |
|
After Width: | Height: | Size: 6.4 KiB |
|
After Width: | Height: | Size: 56 KiB |
@ -0,0 +1,105 @@ |
|||
# 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: |
|||
|
|||
1. **Ask** to understand the area and the existing conventions. |
|||
2. **Plan** to turn the requirement into a reviewable implementation path. |
|||
3. **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. |
|||
|
After Width: | Height: | Size: 37 KiB |
|
After Width: | Height: | Size: 4.1 KiB |
|
After Width: | Height: | Size: 12 KiB |
|
After Width: | Height: | Size: 7.1 KiB |
|
After Width: | Height: | Size: 24 KiB |
@ -0,0 +1,138 @@ |
|||
# 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. |
|||
@ -0,0 +1,143 @@ |
|||
# 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](https://addyosmani.com/blog/agent-harness-engineering/) 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: |
|||
|
|||
```text |
|||
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: |
|||
|
|||
```text |
|||
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.** |
|||
|
After Width: | Height: | Size: 215 KiB |
|
After Width: | Height: | Size: 11 KiB |
|
After Width: | Height: | Size: 5.7 KiB |
|
After Width: | Height: | Size: 13 KiB |
@ -0,0 +1,275 @@ |
|||
# 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: |
|||
|
|||
```text |
|||
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: |
|||
|
|||
1. Trigger the problem. |
|||
2. Ask the agent to inspect the runtime evidence. |
|||
3. Let it find the related code. |
|||
4. Apply the fix. |
|||
5. 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: |
|||
|
|||
```text |
|||
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: |
|||
|
|||
```text |
|||
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: |
|||
|
|||
```text |
|||
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`: |
|||
|
|||
```csharp |
|||
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: |
|||
|
|||
```text |
|||
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: |
|||
|
|||
```text |
|||
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: |
|||
|
|||
```text |
|||
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: |
|||
|
|||
```text |
|||
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: |
|||
|
|||
1. Read the runtime exception. |
|||
2. Correlate it with logs and requests. |
|||
3. Find the failing code path. |
|||
4. Apply or suggest the focused fix. |
|||
5. 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](https://abp.io/community/articles/deep-dive-on-abp-ai-agent-1-agent-plan-and-ask-modes-62wteg9t), 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._ |
|||
|
After Width: | Height: | Size: 2.3 KiB |
|
After Width: | Height: | Size: 1003 B |
|
After Width: | Height: | Size: 2.0 KiB |
|
After Width: | Height: | Size: 2.8 KiB |
|
After Width: | Height: | Size: 1017 B |
|
After Width: | Height: | Size: 18 KiB |
|
After Width: | Height: | Size: 275 KiB |
|
After Width: | Height: | Size: 2.4 KiB |
|
After Width: | Height: | Size: 2.7 KiB |
|
After Width: | Height: | Size: 12 KiB |
|
After Width: | Height: | Size: 16 KiB |
|
After Width: | Height: | Size: 28 KiB |
|
After Width: | Height: | Size: 39 KiB |
|
After Width: | Height: | Size: 36 KiB |
|
After Width: | Height: | Size: 22 KiB |
|
After Width: | Height: | Size: 34 KiB |
|
After Width: | Height: | Size: 17 KiB |
|
After Width: | Height: | Size: 5.9 KiB |
|
After Width: | Height: | Size: 496 KiB |
|
After Width: | Height: | Size: 23 KiB |
@ -0,0 +1,315 @@ |
|||
# 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](https://abp.io/community/articles/deep-dive-on-abp-ai-agent-4-integrated-abp-studio-tools-be2xa2om) 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](https://github.com/punkpeye/awesome-mcp-servers) repository, which collects MCP servers across many categories. |
|||
|
|||
For concrete examples, there are MCP servers for [Prometheus metrics](https://github.com/pab1it0/prometheus-mcp-server), [AWS Managed Prometheus](https://github.com/awslabs/mcp/tree/main/src/prometheus-mcp-server), and [SEO analysis](https://github.com/g-battaglia/mcp-seo). 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: |
|||
|
|||
```text |
|||
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: |
|||
|
|||
```text |
|||
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: |
|||
|
|||
```text |
|||
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: |
|||
|
|||
```text |
|||
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: |
|||
|
|||
```text |
|||
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: |
|||
|
|||
```text |
|||
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: |
|||
|
|||
```text |
|||
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: |
|||
|
|||
1. Run the external SEO audit. |
|||
2. Read the score and category breakdown. |
|||
3. Identify the weakest areas. |
|||
4. Suggest concrete technical or content improvements. |
|||
5. 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: |
|||
|
|||
```text |
|||
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: |
|||
|
|||
1. MCP brings in the external context. |
|||
2. ABP-aware reasoning maps it to the solution. |
|||
3. 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: |
|||
|
|||
1. Understand the requirement from outside the repository. |
|||
2. Find where that behavior lives in the ABP solution. |
|||
3. Make the smallest correct change. |
|||
4. 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. |
|||
|
After Width: | Height: | Size: 4.8 KiB |
|
After Width: | Height: | Size: 13 KiB |
|
After Width: | Height: | Size: 81 KiB |
|
After Width: | Height: | Size: 89 KiB |
|
After Width: | Height: | Size: 93 KiB |
|
After Width: | Height: | Size: 9.7 KiB |
|
After Width: | Height: | Size: 16 KiB |
|
After Width: | Height: | Size: 9.8 KiB |
|
After Width: | Height: | Size: 48 KiB |
|
After Width: | Height: | Size: 12 KiB |
|
After Width: | Height: | Size: 6.0 KiB |
@ -0,0 +1,212 @@ |
|||
# 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: |
|||
|
|||
```text |
|||
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: |
|||
|
|||
```text |
|||
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: |
|||
|
|||
1. Pick the issue. |
|||
2. Create a branch for it. |
|||
3. Send the relevant context to ABP Agent. |
|||
4. Let the agent inspect the solution and implement the change. |
|||
5. 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.** |
|||
|
After Width: | Height: | Size: 18 KiB |
|
After Width: | Height: | Size: 32 KiB |
@ -0,0 +1,157 @@ |
|||
# 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: |
|||
|
|||
```text |
|||
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: |
|||
|
|||
```text |
|||
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: |
|||
|
|||
```text |
|||
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.** |
|||
|
After Width: | Height: | Size: 17 KiB |
|
After Width: | Height: | Size: 18 KiB |
|
After Width: | Height: | Size: 425 KiB |
|
After Width: | Height: | Size: 32 KiB |
@ -0,0 +1,90 @@ |
|||
# 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: |
|||
|
|||
```text |
|||
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. |
|||
|
After Width: | Height: | Size: 18 KiB |
@ -0,0 +1,209 @@ |
|||
# 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. |
|||
|
|||
_**Choose a Workflow and Scope before sending your prompt:**_ |
|||
|
|||
 |
|||
|
|||
_**The selected workflow can be configured through Workflow Settings, where you can create, edit, and manage reusable workflows for common development tasks:**_ |
|||
|
|||
 |
|||
|
|||
For me, the value is not only automation. It is also consistency. |
|||
|
|||
Instead of asking: |
|||
|
|||
```text |
|||
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: |
|||
|
|||
```text |
|||
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: |
|||
|
|||
```text |
|||
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: |
|||
|
|||
```text |
|||
Run whatever commands seem appropriate. |
|||
``` |
|||
|
|||
I can say: |
|||
|
|||
```text |
|||
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.** |
|||
|
After Width: | Height: | Size: 67 KiB |
|
After Width: | Height: | Size: 7.6 KiB |
|
After Width: | Height: | Size: 37 KiB |
|
After Width: | Height: | Size: 16 KiB |
Some files were not shown because too many files changed in this diff
Loading…
Reference in new issue