Blog

Agentic Tools for Android Development: My Practical Experience with Claude

Sep 24, 2026 6 min read Aravind

github.com/aravindusdev/agents-in-android

Introduction

While working with AI-assisted development, I experimented with different ways of structuring agents for Android development.

My main goal was simple:

Instead of using one general-purpose AI agent for everything, can I give different development activities their own focused context and responsibilities?

For Android projects, this becomes particularly interesting because development can involve architecture, Kotlin, Jetpack Compose, testing, security, AOSP, Android Automotive, debugging, and documentation.

During my experiments with Claude, I found three useful ways to think about agent-based development:

Programmatic agents using the Agent SDK
Project-level Markdown subagents in Claude Code
Collaborative Agent Teams for exploratory work

They are not replacements for each other. Each one fits a different type of engineering problem.

1. Programmatic Agents — Agent SDK

The first approach is to build the agent programmatically.

Instead of only writing instructions for an AI coding session, the agent becomes part of an application or service. The developer controls how the agent is created, what tools it can use, and how it participates in the surrounding workflow.

I see this approach as useful when the agent needs to become part of a larger engineering system.

Android examples

A programmatic Android development agent could be used for:

automated code analysis
CI/CD workflows
pull-request analysis
API-driven code review
automated documentation generation
controlled engineering workflows
large-scale repository analysis

For example:

Pull Request
      ↓
Agent
      ↓
Analyze Android changes
      ↓
Run selected checks
      ↓
Generate review result
      ↓
CI / Developer Platform

This is more suitable when I want the AI capability to become an actual component of a development platform rather than simply a helper inside my coding session.

2. Markdown-Based Agents in Claude Code

The second approach is much closer to everyday Android development.

I can define specialist agents as Markdown files inside the project:

.claude/
└── agents/
    ├── android-architect.md
    ├── kotlin-reviewer.md
    ├── compose-reviewer.md
    ├── android-test-engineer.md
    ├── security-reviewer.md
    └── aaos-reviewer.md

Each file represents a focused specialist.

The Markdown file can contain frontmatter and instructions describing the agent's responsibility.

For example, an Android architecture agent can be instructed to focus on:

module boundaries
dependency direction
lifecycle
state management
maintainability
testability

A Kotlin agent can focus on:

coroutines
Flow
null safety
Kotlin idioms
concurrency
readability

An Android test agent can focus on:

unit tests
instrumentation tests
UI tests
test coverage
flaky tests

An AAOS specialist can focus on areas such as:

Android Automotive architecture
system services
AIDL/Binder boundaries
VHAL-related code
permissions
system applications

This is the approach I find particularly interesting for day-to-day Android development because the agent definitions can live together with the project.

The important part is not creating many agents.

The important part is giving each agent a clear responsibility.

3. Agent Teams

The third approach is different.

Instead of creating a permanent specialist for every task, I can use multiple agents when a problem benefits from different perspectives.

For example, suppose I am reviewing an Android Automotive architecture.

One perspective could investigate the architecture.

Another could investigate security.

Another could investigate testing.

Another could investigate platform-specific considerations.

Conceptually:

             Architecture Problem
                      │
        ┌─────────────┼─────────────┐
        │             │             │
   Architecture    Security      Testing
      Agent          Agent         Agent
        │             │             │
        └─────────────┼─────────────┘
                      │
                Final Analysis

This is useful for problems where I don't necessarily know the answer in advance and want several independent technical perspectives.

I would use this type of approach for:

architecture exploration
design reviews
parallel technical investigation
comparing implementation approaches
complex debugging investigations
research-oriented engineering tasks

For a small task such as changing a function name, this level of orchestration would be unnecessary.

4. How I Map This to Android Development

After experimenting with these approaches, I think about them in three practical categories.

Approach	How I would use it
Agent SDK	Build AI capabilities into a larger engineering system
Markdown Agents	Create reusable Android specialists inside a repository
Agent Teams	Investigate complex problems from multiple perspectives

This gives me a simple mental model:

Production automation
        ↓
    Agent SDK

Daily project development
        ↓
 Markdown-based agents

Exploration and complex reviews
        ↓
    Agent Teams

5. A Practical Android Agent Setup

For an Android project, I don't think I need dozens of agents.

A small group of focused agents is enough to cover many common activities:

Android Project
│
├── Android Architect
├── Kotlin Reviewer
├── Compose Reviewer
├── Test Engineer
├── Security Reviewer
├── Performance Reviewer
└── AAOS Reviewer

Each agent should have a narrow responsibility.

For example:

Android Architect

Reviews the overall design and module structure.

Kotlin Reviewer

Reviews Kotlin implementation and coroutine/concurrency usage.

Compose Reviewer

Reviews Compose state, UI architecture, and recomposition-related concerns.

Test Engineer

Identifies missing tests and evaluates the existing test strategy.

Security Reviewer

Looks at permissions, IPC, exported components, data handling, and security boundaries.

Performance Reviewer

Looks for potential performance problems and identifies where measurement is required.

AAOS Reviewer

Focuses on Android Automotive and system-level concerns when the project actually contains AAOS/AOSP-related code.

6. One Important Lesson: Don't Create Agents Just for the Sake of Creating Agents

One of the things I noticed during experimentation is that adding more agents does not automatically make development better.

If three agents are doing almost the same job, I am simply increasing complexity.

A better approach is:

Task
  ↓
Identify the actual problem
  ↓
Select the relevant specialist
  ↓
Give it focused context
  ↓
Validate the result

For example:

Simple Kotlin change
        ↓
Kotlin Reviewer

But:

AAOS architecture change
        ↓
Android Architect
        +
AAOS Reviewer
        +
Security Reviewer
        +
Test Engineer

The number of agents should follow the complexity of the problem.

7. Preventing Hallucinations in Android Development

This is particularly important when working with AOSP and Android Automotive.

I don't want an agent to confidently create an API or platform behavior that does not exist.

Therefore, one of the rules I use is:

Verify first, implement second.

The agent should inspect:

existing source code
Gradle configuration
AndroidManifest files
AIDL interfaces
framework code where available
existing tests
official Android/AOSP documentation when required

The result should distinguish between:

Verified
    ↓
Found in source/documentation

Inferred
    ↓
Reasonable conclusion from available evidence

Unknown
    ↓
Cannot be verified from the available information

This is much safer than allowing an agent to fill missing information with assumptions.

8. Agent Boundaries Are More Important Than Personas

I also found that a specialist agent does not need a huge personality prompt.

Clear engineering boundaries are more useful.

For example:

Do:
- inspect the existing implementation
- follow project conventions
- explain assumptions
- run relevant tests when possible
- report failures honestly

Do not:
- invent APIs
- modify unrelated modules
- disable tests
- remove security controls
- assume proprietary OEM behavior
- claim something was verified when it was not

These rules help keep the agent focused on engineering work rather than generating plausible-looking answers.

9. Where This Can Help in Android Automotive

This approach becomes particularly interesting for Android Automotive because the system can span multiple layers:

Application
      ↓
Android Framework
      ↓
System Services
      ↓
AIDL / Binder
      ↓
HAL / VHAL
      ↓
Vehicle / Vendor Layer

A single development task can therefore involve different technical areas.

For example, a feature touching a vehicle-related service could require:

architecture review
Android framework review
IPC review
security review
testing

Instead of asking one general agent to understand everything, I can divide the investigation into focused responsibilities.

This does not mean every change requires every agent.

The agents should only be used where they add value.

10. My Practical Model

After experimenting with these approaches, my preferred model for Android development is:

                    Android AI Workflow
                           │
          ┌────────────────┼────────────────┐
          │                │                │
      Automation       Development      Exploration
          │                │                │
      Agent SDK       Markdown Agents   Agent Teams

Agent SDK

I would use this when I want to build an actual AI-powered engineering service or automation.

Markdown Agents

I would use these for reusable specialists that belong to an Android project.

Agent Teams

I would use them when the problem benefits from several independent perspectives.

Conclusion

My main takeaway from experimenting with agentic development is that the goal is not to create more agents.

The goal is to give the right amount of context and responsibility to the right agent for the problem.

For Android development, I see a practical combination:

Agent SDK
    → Engineering automation

Markdown Agents
    → Daily Android development

Agent Teams
    → Complex exploration and design reviews

For my Android workflow, the Markdown-based specialist approach is particularly practical because the agents can stay with the repository and evolve alongside the codebase.

The next step is to build a small set of Android-focused agents rather than one large "do everything" agent—and then expand the setup only when a real development problem justifies another specialist.

← All posts