Target Component
Core Services (Frontend UI/Backend API)
Enhancement Description
Problem
When integrating PentAGI into automated pipelines (e.g. weekly security reviews across multiple repositories), there is no way to control how many flows run concurrently. Calling createFlow N times in sequence starts all N flows immediately, spinning up N Kali Linux containers simultaneously and saturating host resources.
Currently the only workaround is implementing an external polling loop:
- Call createFlow for a batch of N
- Poll GET /api/v1/flows/{id} until status == completed | failed
- Launch next batch manually
This adds significant complexity to any external orchestration layer.
Proposed Solution
Two complementary additions:
- MAX_CONCURRENT_FLOWS environment variable
A simple cap on how many flows can be in active status simultaneously. Flows created beyond the cap would enter a queued status at the Flow level and be promoted automatically as slots free up.
- Webhook / callback on flow completion
A configurable WEBHOOK_URL that PentAGI calls with a POST when a flow transitions to completed or failed. This eliminates the need for external polling loops entirely.
Current Workaround
External batch orchestration via polling — functional but requires building and maintaining a custom polling loop outside PentAGI.
Use Case
Automated weekly security pipeline across 30+ repositories:
- Each repo triggers a PentAGI flow with its findings
- Without concurrency control, 30 Kali containers start simultaneously
- With MAX_CONCURRENT_FLOWS=5, PentAGI would self-manage the queue and process them in controlled batches
Technical Details
No response
Designs and Mockups
No response
Alternative Solutions
No response
Verification
Target Component
Core Services (Frontend UI/Backend API)
Enhancement Description
Problem
When integrating PentAGI into automated pipelines (e.g. weekly security reviews across multiple repositories), there is no way to control how many flows run concurrently. Calling createFlow N times in sequence starts all N flows immediately, spinning up N Kali Linux containers simultaneously and saturating host resources.
Currently the only workaround is implementing an external polling loop:
This adds significant complexity to any external orchestration layer.
Proposed Solution
Two complementary additions:
A simple cap on how many flows can be in active status simultaneously. Flows created beyond the cap would enter a queued status at the Flow level and be promoted automatically as slots free up.
A configurable WEBHOOK_URL that PentAGI calls with a POST when a flow transitions to completed or failed. This eliminates the need for external polling loops entirely.
Current Workaround
External batch orchestration via polling — functional but requires building and maintaining a custom polling loop outside PentAGI.
Use Case
Automated weekly security pipeline across 30+ repositories:
Technical Details
No response
Designs and Mockups
No response
Alternative Solutions
No response
Verification