Forward Deployed Engineer - Project Case Study · 2025 – Present
AIMO: Enterprise AI Agent Platform
Product pageEngagement Snapshot
What I built, who it is for, and where my ownership starts and stops.
No-Code Enterprise Agent Platform
A platform for building AI agents on any LLM, wired into the tools a workspace already runs on (Slack, Notion, GitHub, Salesforce and 20+ other services), so agents act with full organisational context instead of a blank prompt.
Role
Founder and lead engineer
Scope
Connector layer, memory graph, permission engine, LLM router, product
Customer & Problem
Who this is for, the messy reality they work in, and why the system needed to exist.
Who it is for
Teams of 10 to several hundred people whose knowledge is spread across chat, docs, code, CRM and storage, and who want agents that know their organisation.
What was wrong before
Company knowledge is scattered across chat, docs, code, CRM and storage. Agents built on a blank prompt know nothing about the organisation.
Who needed it
Teams that want agents grounded in their own context, without engineering a bespoke integration for every tool and model.
If nothing changed
Answers stay generic or, worse, leak data across teams when naive context-stuffing ignores who is allowed to see what.
The environment I had to work in
- Every tool has its own auth model, schema and rate limits, so no two integrations behave alike.
- Permissions differ per tool and per person. An answer that is fine for one team can be a leak for another.
- Customers already have LLM preferences or compliance rules, so the platform cannot assume one provider.
- Data lives in systems of record the customer will not move, so the platform has to read in place.
Discovery & Requirements
The questions I ask first, and the requirements every decision below traces back to.
Discovery questions
- 01Which 3 to 5 tools hold the real answers today, and who owns each?
- 02Who is allowed to see what, and where is that already written down?
- 03Which LLM providers are approved, and can any data leave a region?
- 04What does a good answer look like, and who will judge it?
- 05Who administers the platform after go-live?
Requirements
System Architecture
The centerpiece. The diagram is the easy part - the value is in why each boundary exists.
Why this boundary exists · Slack
Communication sources feed decisions and context.
Click any component to see why it is a separate boundary.
Integrations & Data
Where each category of information lives, what it connects to, and why.
Critical Architecture Decisions
Architecture decision records: the problem, the options, the call, and when to revisit it.
ADR-001 - Where to enforce access control
Options considered
Decision
At retrieval time, via the permission engine.
- Problem
- Enterprise context is sensitive and differs per user.
- Reasoning
- Filtering context before it reaches the model guarantees the model never sees restricted data.
- Trade-offs
- Permissions from each source must be mirrored and kept in sync.
- Revisit when
- If source-native permission APIs become reliable enough to query live.
Deployment & Handoff
How it gets installed and shipped, what it runs on, and how it is handed over so the customer can run it.
Git.
Rollout and handoff
Connector-by-connector rollout
Start with the one or two sources the team actually uses, approve scopes per tool, then widen. Each connector is isolated so a broken one does not affect the rest.
Permission mapping before launch
Roles and teams are mapped to source permissions and checked with real users before agents are switched on.
Provider choice is configuration
The LLM router lets the customer pick and change providers without touching agents.
Admin visibility
Usage tracking per provider and citations on every answer give admins something to audit and tune.
Reliability Engineering
Failure thinking: what breaks, what catches it, and what actually went wrong.
Served by Primary LLM
Security Architecture
Every request passes these gates in order.
Authenticate.
Tenant and team isolation
Answers are scoped to the asker's role and team before reaching a model.
Least privilege connectors
Connectors request only the scopes a workspace approves.
Prompt injection
Content from tools is treated as data, not instructions.
Secrets
OAuth tokens and provider keys are stored encrypted and never sent to models.
Results
Only outcomes that can be substantiated. Adoption figures are added when they are real.
Engineering
Field Lessons
What this project taught me about shipping AI into someone else's environment.
L1
Access control belongs before the model
Filtering retrieved context is enforceable. Asking a prompt to keep secrets is not.
L2
Integrations are the product
Most of the effort in an enterprise agent is in connectors and permissions, not the LLM call.
L3
Start narrow
Two well-connected tools beat twenty half-connected ones for the first deployment.
Request / Execution Flow
One real request traced through the system - dynamic behaviour, not just boxes.
User asks agent.In Slack, Teams or the web app.
Deep-Dive Architecture
The technically difficult pieces, step by step.
Authorise.Workspace approves scopes for a tool.
AI Architecture
Model strategy, retrieval, and evaluation - the parts specific to an AI system.
Model strategy
Fast models
Routine lookups and summaries.
Frontier models
Hard reasoning across many sources.
Customer-chosen
Any provider a customer prefers or is required to use.
Retrieval
Observability
The observability model, not a tool name.
Illustrative span layout - shows nesting, not measured durations.
Performance Engineering
Where the bottlenecks were, and what moved the numbers.
What caused the improvement
- Retrieval and filtering run before the LLM, keeping prompts small.
- Connector sync runs off the request path.
- Provider routing avoids single-vendor slowdowns.
No public benchmark numbers yet; this section will be filled in once measured.
Architecture Principles
The architecture followed from these, not from a shopping list of technologies.
P1
Context is the product
The value is what the agent knows about the organisation, not the model itself.
P2
Permissions before prompts
Access control is applied to retrieved context, not left to model behaviour.
P3
Model independence
No customer should be locked to one LLM vendor.
P4
Connectors are isolated
A broken integration must not affect the rest of the memory.
P5
Citations always
Answers stay traceable to sources, whichever model wrote them.
Alternatives Rejected
Understanding the solution space, not just the final implementation.
Each integration is duplicated effort and ungoverned; a shared connector layer is built once.
What I Would Change Today
A self-critique of the architecture.
- Publish evaluation numbers for answer quality and citation coverage.
- Separate connector ingestion into its own scalable service earlier.
- Sync source-native permissions continuously instead of periodically.
My Role
What I owned, co-designed, influenced, and implemented personally.
Owned
- · Product architecture
- · Permission engine
- · LLM router
Co-designed
- · Connector framework
Influenced
- -
Implemented personally
- · Memory graph
- · Core integrations