Forter shifted from scattered AI experiments to a coordinated program that let 200 engineers and non‑engineers build internal AI agents in just two weeks. The change hinged on deploying custom Model Context Protocol (MCP) servers, mixing no‑code and code‑based tooling, and deliberately avoiding the complexity of Retrieval‑Augmented Generation (RAG) pipelines, while bringing security and legal stakeholders into the loop early.
Custom MCP Server as Integration Backbone
Using a dedicated MCP server gave teams a consistent protocol for passing context and prompts to underlying models. For platform engineers this means a single service to operate, monitor, and scale rather than multiple ad‑hoc model calls. The server abstracts model versioning and can be updated without touching downstream agent code, simplifying deployment pipelines.
Hybrid No‑Code/Code Development Model
Forter combined visual, no‑code builders with traditional code‑first environments. This approach lets non‑technical staff prototype agents quickly, while developers can extend or harden those prototypes with custom logic. The dual path reduces the barrier to entry but introduces a need for governance around which agents move from no‑code prototypes to production‑grade code.
Security and Legal Alignment as a Project Driver
By involving security and legal teams from the start, the program avoided later compliance rework. Practitioners should note that any internal agent exposing data or invoking external services will need the same review cadence as other internal services, and that the MCP server becomes a focal point for audit and policy enforcement.
Related CloudNinjas coverage: AI engineering.
What This Means For Practitioners
Engineers should evaluate the maturity of their MCP implementation, ensure monitoring and scaling practices are in place, and define clear hand‑off criteria between no‑code prototypes and code‑based production agents. Security and compliance groups must establish review checkpoints that align with the rapid development cadence. Finally, teams should keep an eye on future needs for RAG capabilities, as the current avoidance of RAG may need revisiting as data‑driven use cases evolve.
