Analyzing my AI agent orchestration layer with Repowise

[Sreeyukth]

I tested Repowise on my AI Co-Investor FastAPI microservice, which contains multiple financial AI-agent workflows for portfolio analysis and investment-related reasoning.The most interesting finding was that the highest-risk area was not the API layer, routing system, or data models. Instead, Repowise identified the agent execution layer as the main complexity concentration point.

After Repository analysis,Repowise generated:

Files analyzed: 22
Symbols extracted: 77
Dependency graph: 121 nodes, 180 edges
Git history: 19 files indexed

Average health score: 9.5/10
Lowest health component: src/agents/portfolio_health.py
Score: 6.5/10

The architecture and knowledge graph views showed a mostly healthy system, but highlighted that one agent module carried most of the implementation complexity.
Key Finding: Hidden complexity inside the AI-agent execution layer

The most interesting Repowise finding was that the highest-risk area was not the API layer or data models, but the agent orchestration logic.
Repowise flagged:

src/agents/portfolio_health.py

Health score: 6.5/10
Cyclomatic Complexity: 23
Nesting Depth: 4

At first this surprised me because the code looked clean from a normal review perspective — it used async execution, concurrent API calls, typed schemas, and helper functions.

However, Repowise showed that the issue was architectural. The main run() method had accumulated too many responsibilities:

• fetching market data
• handling FX conversion
• calculating portfolio metrics
• evaluating risk
• comparing benchmarks
• generating responses

The code worked, but the dependency and complexity analysis showed that future modifications would become harder as the agent grows.

Repowise also detected unused agent capabilities:

1 unreachable file
14 unused exports
~112 potential cleanup lines

Several intended tools such as investment_strategy, risk_assessment, and portfolio_optimization existed in the repository but were not connected to the execution flow.

Another useful finding was broad exception handling around external services. A failed market-data request could silently fall back without making the failure observable.

The biggest takeaway was that traditional testing showed whether my AI agent worked, while Repowise showed whether the architecture would remain maintainable as the system scales.