A networked Multi-Agent System (MAS) architected for ALMARKAZ's 11-person industrial real estate team. Six domain agents plus a Central Orchestrator handle end-to-end workflows — from lease origination through financial close to government filings — with human-in-the-loop approval gates at every key decision point.
7
Total Agents
~75%
Routine Task Automation
24/7
Operational Coverage
12
Cross-Dept Workflows
3
Rollout Phases
9mo
Full Deploy Timeline
Current Organisation (11 FTEs)
👑
CEO
Executive Director
AGENT-0
🧭
Strategy Head
Head of Functional Teams
ORCHESTRATOR
🤝
Sales
1 Manager
AGENT-2
💰
Finance
3 Members
AGENT-3
🏗️
Projects
2 Members
AGENT-4
📋
Admin
2 Members
AGENT-5
Architecture Principles
HIERARCHICAL MAS PATTERN
Strategy Head is elevated to Orchestrator Agent — decomposes CEO tasks, routes to domain agents, reconciles outputs, and escalates decisions requiring human judgment.
HUMAN-IN-THE-LOOP GATES
Agents operate autonomously for routine tasks. Financial approvals >AED 50K, legal commitments, and government submissions always require human sign-off before execution.
SHARED MEMORY LAYER
All agents read/write to a central knowledge graph (property portfolio, lease database, project register). No siloed data — every agent has full context.
EVENT-DRIVEN TRIGGERS
Workflows fire automatically on business events: lease expiry alert, payment overdue, construction milestone, document deadline. Agents don't wait for human prompts.
Agent Architecture
7 Agents — Roles, Tools & Capabilities
Each agent is a purpose-built LLM system with defined scope, tool access, decision authority, and escalation protocols. Agents share a memory layer and communicate via structured JSON task queues with full audit trails.
🎯
ORCHESTRATOR · AGENT-1
Strategy & Coordination Agent
Replaces: Strategy Head function · Supervises all 6 domain agents
Core Responsibilities
Receives natural-language instructions from CEO and decomposes into structured sub-tasks for domain agents
Monitors KPIs across all departments in real-time; generates weekly CEO briefings automatically
Routes cross-functional workflows (e.g. signed LOI → finance → legal → admin → GRO chain)
Flags bottlenecks, SLA breaches, and deadline risks with escalation to CEO
Drafts PMLA Committee presentations from live data; quarterly Board pack generation
Strategic benchmarking: market rent analysis, portfolio performance vs peers
Automation Triggers
→End of month → Pull all agent reports → Compile management pack → Route to CEO for approval
Monitors UAE regulatory changes (RERA, ADM zoning, ESR, UBO) and flags business impact
Tracks government portal application statuses; auto-follow-up on pending submissions
Tools & Integrations
Tamm / DLD PortalMOHRE PortalICA / GDRFASharePointDocuSign
Connects To
OrchestratorFinanceSalesDevelopment
👑
EXECUTIVE INTERFACE · AGENT-0
CEO Intelligence Agent
Personal AI Chief of Staff · Natural-language command interface for CEO
Executive Decision Support
Daily CEO briefing: occupancy snapshot, collections status, active project milestone, pipeline value — auto-delivered 8am
Natural-language query interface: "What is our Q3 NOI vs budget?" → pulls data → generates answer in 30 seconds
Approval queue management: routes decisions requiring CEO sign-off with full context and recommendation
Drafts investor/Board communications from financial and operational data on demand
Scenario analysis: "What is the IRR if we develop the northern plot at AED 2,400/sqm?" → live model run
Tools & Integrations
Claude API (advanced)All agent APIsAnalytics DBFinancial ModelMobile App
Connects To
OrchestratorFinanceSales
Multi-Agent Network
Networked Agentic Model — Data Flow Map
Interactive network showing how agents communicate. Hover over nodes to see responsibilities. Animated edges show active data flows. Bold edges indicate high-frequency workflows.
Document retrieval, regulatory alert, compliance status
Deadline-based + reactive
Daily
Automated Workflows
12 Key Cross-Functional Automation Flows
Each workflow shows how agents hand off tasks autonomously, with human approval gates (🔐) at critical decision points. Agents operate 24/7; humans only engage at approval checkpoints.
Overnight collections, outstanding receivables, cash position, any overdue tenants.
Finance Agent
→
07:10
Sales Pull
Occupancy rate, pipeline deals, new enquiries overnight, renewal watch list.
Sales Agent
→
07:20
Project Pull
Construction progress, open maintenance tickets, FM SLA status, utility anomalies.
Dev Agent
→
07:30
AI Synthesis
Orchestrator synthesises all data into 1-page briefing. Flags top 3 actions requiring CEO attention.
Orchestrator
→
08:00
CEO Delivered
Briefing pushed to CEO mobile app, email, and Teams channel. Ready before first meeting.
CEO Agent
Implementation Roadmap
3-Phase Deployment — 9 Months
Phased rollout minimises operational disruption. Each phase delivers immediate productivity gains before the next layer is added. Human-in-the-loop gates remain in place throughout — agents augment humans, not replace them.
PHASE 1 · MONTHS 1–3
Foundation Layer
Deploy CEO Agent + Orchestrator. Connect to existing CRM and accounting system. Automate daily briefing and monthly reporting. Quick wins: zero manual report compilation.
PHASE 2 · MONTHS 4–6
Operations Layer
Deploy Sales + Finance + Admin agents. Automate enquiry response, invoice generation, bank reconciliation, lease renewal alerts, document management and government portal tracking.
PHASE 3 · MONTHS 7–9
Intelligence Layer
Deploy Development Agent with FM and construction integrations. Activate full inter-agent network. Enable predictive analytics: rent forecasting, capex planning, tenant churn risk scoring.
Document management, visa tracking, Ejari, govt portal submissions
SharePoint, DLD/MOHRE portals, DocuSign
~35 hrs/mo
MED
Development Agent
Phase 3
Programme monitoring, payment certs, FM SLA, maintenance tickets
Procore, CAFM, IoT sensors, BIM 360
~50 hrs/mo
MED
Technology Stack Recommendation
AI BACKBONE
Claude claude-sonnet-4-20250514 as primary LLM for all agents. OpenAI embeddings for semantic search over lease/property database. LangChain / LlamaIndex for agent orchestration framework.
DATA LAYER
PostgreSQL for structured data (leases, financials, projects). Pinecone/Weaviate vector DB for document semantic search. Redis for agent memory and task queue. S3-compatible storage for documents.
INTEGRATIONS
Xero for accounting. Procore for construction PM. Microsoft 365 for documents. DocuSign for e-signatures. Twilio for WhatsApp. Power Automate for workflow triggers.
SECURITY & CONTROL
Role-based access per agent. All agent actions logged to immutable audit trail. Human approval gates via mobile app. UAE data residency compliance. Anthropic's Constitutional AI safeguards.
LA Digital · Building On Your Plan
Our Approach
Experiment 2 is the destination — the seven-agent network (your six domain agents plus the orchestrator), the sequencing logic, the human sign-off gates. We are not redesigning any of it. This is how we turn that ambition into something we can start now, so the build plan that follows is buildable from week one, not a vision waiting on everything else to be ready.
Foundations first
A framework for measurable experiments — not a one-off
Standing up an agent that demos well is the easy part — a working chat over your data can come together quickly. The hard part, and where most AI pilots quietly stall, is everything around it: versioning, environments, hosting, evals, audit, cost control, model-portability. So alongside the first agent we build the framework these run on — the same software-engineering discipline we bring to every production system by default.
Then each agent is a measurable experiment on top of that framework: a hypothesis with a number, that we version, measure, compare, roll back, and promote only when it proves out. The reporting agent is experiment one. That is the difference between a demo and something the board, your auditors, and procurement can trust at scale.
Build & ship
Version control & code review
Staging → production environments
CI/CD with eval-gating — a change can't ship if it regresses quality
Repeatable, documented deploys
Run & host
Hosted on infrastructure you own or in-country
Proper URLs, access control, defined availability
Public where it should be, private / SSO where it's sensitive
Not a script on someone's laptop
Observe & govern
Request / response logging & tracing
Immutable audit trail
Usage tracking & per-department cost budgets
Monitoring dashboard (OpenTelemetry)
Model layer
Switch LLMs by config, no rebuild
Start on frontier APIs; route to on-prem for sensitive data when justified
Cost-optimised per task
No provider lock-in
Destination → first move
Start with reporting
The network is the goal. We'd open one step earlier than your Phase 1 — with a leadership reporting agent: lowest-stakes (internal data only), highest-visibility (leadership sees it weekly), and with a real head start — StayAhead, our existing pipeline, already gives us the chart-composition and branded-report layer. A sequencing call we make together, not a change to your plan.
Data reality
Start on a data slice
Oracle is mid-standardisation, so we don't wait for the whole programme. We begin with a slice — an export or extract is enough — and repoint to the live MCP interface when it lands. The vision is unchanged; this just sets a realistic start line. Being involved during standardisation is also how we keep early answers accurate.
Human-in-the-loop
Your gates, kept
The gates stay exactly as you wrote them: anything over AED 50K, legal commitments, and government submissions always need a person to sign off. The action-taking agents — money, leases, filings — are later phases, behind the proven foundation. Read-and-advise first.
Owned by you
No lock-in
Built in git, documented, on open standards — MCP, OpenTelemetry, OIDC. The model sits behind an abstraction, so any task moves between an on-prem model and Claude by config, not rebuild. ALMARKAZ owns the build and can hand it to anyone, anytime.
Sovereignty, precisely
"Doesn't train on your data" is not "stays in country." We map data to handling and are explicit about the v1 path, so there's no contradiction for your infosec people to catch.
Tier
What it means
Use it for
True sovereign
Open-weights model on hardware you control — on-prem GPU, served with vLLM
Confidential board & financial data
Regional managed
e.g. Azure OpenAI UAE North — storage stays in-region, but inference may route abroad. Residency of storage is not residency of processing.
Non-sensitive internal tasks
Zero-retention frontier
Claude / best available models — processed in US/EU, not stored and not trained on
Tasks exposing no sensitive material
For v1 we start API-first. The reporting agent runs on Claude under zero-retention terms — the fastest path to a working result, with no upfront infrastructure spend. Week one classifies the slice with you, and the first demo uses data that's non-sensitive or redacted, so nothing confidential goes off your network before the on-prem path exists. That boundary is enforced at the gateway, not just on paper: a field tagged confidential cannot be sent to an external API — until local inference is stood up, those fields are redacted or held back, not routed out.
Because the model sits behind that gateway, bringing confidential board/financial workloads onto an on-prem open-weights model later is a config change, not a rebuild. So sovereignty is sequenced like everything else: prove the value on the frontier path first, then move sensitive data fully in-house once results justify the hardware — no GPU bet on day one. The table reads bottom-up: v1 lives on the zero-retention frontier tier and climbs to true sovereign as confidential workloads come online.
WHAT v1 IS
A working agent that answers a real ALMARKAZ leadership question with a chart — composed into a branded, board-ready report. Runs API-first on Claude (zero-retention) over a non-sensitive or redacted slice. Read-only and advisory. Validated against figures you already trust, with every number traceable back to its source rows in one click.
WHAT v1 IS NOT
No voice — text proves the point. No leasing, tenant, or live commercial data. It takes no actions and writes nothing back. And it's not blocked on Oracle being finished — we build against today's slice and repoint later.
So the plan that follows is buildable
None of this changes where you're going — it sets an honest starting line. The Build Plan tab is the tangible version: what we stand up, in what order, what we need from you, and how we'll both know it's working. It's also the plan referenced in our proposal.
LA Digital · Implementation
The Build Plan
The practical version of Experiment 2: what we actually build first, what we need from you, and how we'll both know it's working. Two things get built from day one — the shared platform, and the first agent on top of it.
TRACK A · FROM DAY ONE
The Platform
The base infrastructure every agent runs on. Built once, it makes every later agent quick to stand up — this is where the real leverage is.
TRACK B · FROM DAY ONE
Agent One — Reporting
The first live agent, running on the platform. Lowest-stakes and highest-visibility — the cleanest way to prove the whole approach. Everything else in Experiment 2 rides this same platform afterwards, and comes faster.
So this plan details one agent — reporting, the only one we commit to and cost now — plus the platform that serves all of them. The platform (Track A) is the leverage: build it once, and the other six agents become quick to stand up. Their order isn't costed here — it's sequenced on proof in the Roadmap tab.
Track A — the base infrastructure
Git-based deploys
Agents live as configuration in git — prompts, tools, settings — version-controlled and reviewable. Nothing important lives only in one person's head.
A model gateway
One layer in front of every model. We start on frontier APIs (Claude) to move fast; sensitive work routes to a local model on your network once that's stood up. Swap either by changing a setting, not rebuilding — never locked to one provider.
An MCP server on Oracle
The single interface every agent reads through. Runs as a least-privilege user against read-only views, with query auditing on.
Knowledge bases
A per-agent retrieval layer over your documents, managed from the dashboard rather than hardcoded.
Monitoring & agent-swap dashboard
Built on OpenTelemetry, so you can see what each agent is doing, what it costs, and roll a version back if you need to.
Usage tracking & budgets
Per-department and per-agent spend, visible and capped, via an AI-gateway pattern in front of every agent.
Microsoft Entra ID login
Access mapped to the Entra groups you already have, via Microsoft SSO — no second user directory to maintain.
Immutable audit trail
Every agent action logged. This is also the evidence your security and procurement people will ask for later.
Staging → production & CI/CD
Separate staging and production environments with a continuous-integration pipeline and eval-gating, so changes are tested before they reach the people relying on them.
Hosting & access
Hosted on infrastructure you own or in-country, reached through proper URLs with defined availability — public where it should be, private and behind SSO where it's sensitive.
This is the architecture we build toward, not a month-one delivery. Roughly what's real when (indicative — it grows with the work, at our ~2-day-a-week cadence):
EARLY · WITH AGENT ONE
Git repo & deploys, the model gateway (API-first), request/response logging, and the reporting agent running on a data slice.
You'll see: a real leadership question answered as a chart, from your own slice.
AS IT MATURES
Microsoft Entra SSO, the immutable audit trail, the monitoring dashboard, and staging → production with eval-gating.
You'll see: sign in with your Microsoft account; every figure traceable in the audit log.
LATER · ON PROOF
Per-department budgets, the live MCP-on-Oracle interface, knowledge bases, and on-prem inference for confidential data once results justify the hardware.
You'll see: confidential data answered on-prem; per-department spend visible and capped.
Getting the data
Step
What we do
1
Pick the questions first. We sit with leadership and write down the three real questions they most want answered from their own numbers. The questions decide what data we need — not the other way round.
2
Get a data slice. An export or extract of the relevant operational and financial data is enough to begin. Full live access comes through the MCP server as the platform matures.
3
Classify sensitivity, together. We tag each field with you. Non-sensitive and redacted data runs on Claude (zero-retention) from day one; confidential fields are redacted or held back until on-prem inference is stood up. Enforced at the gateway, not just agreed on paper — a field tagged confidential cannot reach an external API.
4
Set up clean access. With your Oracle integrator, we use read-only views and a least-privilege account, and shape the data so it's sensible for an agent to query.
Track B — agent one: reporting
You ask a real question about your own numbers, and it answers with a chart rather than a wall of text, then composes those charts into a branded report you can take to a board meeting.
What's reused, and what's new. StayAhead — our existing pipeline — already gives us the part that's normally a slog: chart composition, the branded report layer, and turning a structured answer into a finished document. The new work for ALMARKAZ is the layer in front of it: turning a leadership question into the right query over your data, and a verified number traceable back to source. We're adapting a working engine, not inventing the whole thing — and being honest about which half is the real build.
Connect the reporting agent to the data slice (API-first, on Claude).
Build the question-to-chart pipeline — one real question first, then widen to three.
Compose the charts into a branded report template (this is the StayAhead-reuse part).
Validate against known-good figures, widen the question set, and get it into weekly use.
How leadership comes to rely on it: before real use, we validate the agent's answers against figures you already know to be correct, and every figure links back to the source rows through the query audit trail. Output you trust because you can trace it — not output you're asked to take on faith.
THE DEMO MILESTONE
At our ~2-day-a-week cadence, the first working demo lands ~3–4 weeks after data access: a real ALMARKAZ leadership question answered as a chart, composed into a board-ready report. That's the test you can see for yourself — not an adjective, a thing you can put in front of the board. It widens to three questions and into regular weekly use within the first quarter (~90 days).
Being straight about the clock: 8 days/month is real engineer-time, so we quote elapsed weeks at that cadence, not an idealised sprint. If you want the very first chart sooner, we can scope a single-question version inside the first couple of weeks.
How we measure success
We agree the baselines with you in week one, then track the change against them — so the result is measured, not asserted.
What we measure
How
Example target
Reporting-cycle time
Senior hours assembling a reporting pack, before vs after
Cut ~two-thirds by day 90
Time to an answer
Question asked → chart in hand
Under a couple of minutes
Question coverage
Leadership questions answered reliably
3 at demo → 10+ by day 90
Verifiable to source
Share of figures traceable to source rows
100%
Real usage
Used in the actual monthly management / board cycle
By day 90
The first agent's number, concretely
Board-pack assembly today takes roughly [confirm: X] senior hours per cycle across [confirm: Y] cycles a year ≈ [confirm: AED Z]/year of senior time. A two-thirds cut is the first line we put against the AED 20k/month — measured from the baseline we agree in week one, not assumed. (We fill these three numbers with you in week one.)
The platform gets one metric that matters more than it looks: how long it takes to stand up the next agent. That number should fall with each agent we add — the proof the platform is doing its job. Across the agents that go live, the hours reclaimed build toward the ~220 hours/month your Experiment 2 doc estimates — your target, demonstrated agent by agent over time, not our promise on day one.
THE HONEST RISKS
The clock to first demo starts at data access — yours to clear. If it slips, the platform work (repo, gateway, logging, SSO) needs no data, so the early days go into that instead and no time is lost.
Early accuracy tracks data quality. The Oracle data is mid-standardisation — exactly why we want to be involved now.
Continuity: the day-to-day is one embedded engineer. LA Digital stands behind it with a named backup ([confirm: backup engineer]) who can pick up from the documented repo, plus a written handover standard — so a board cycle never waits on one person's calendar.
WHAT WE NEED FROM YOU
A named sponsor (Anuj) and a data owner.
A data slice for the first questions.
The three leadership questions to answer first.
A line to your Oracle integrator for read-only views.
An IT contact for the Entra SSO setup.
OWNERSHIP
ALMARKAZ owns its build — connectors, report templates, workflows, tuned prompts. LA Digital keeps the reusable framework underneath. No per-entity licence, nothing to hold over you.
SECURITY
PDPL-aligned: agent one processes no personal data — your own operational and financial figures. Market-sensitive board data is classified and kept off external APIs until on-prem inference is live (handled as inside-information, separate from PDPL). We provide the audit artifacts your compliance team needs; we don't claim certifications we don't hold. One-page data-flow diagram for infosec early on.
EXIT
Rolling monthly, 30 days' notice either way. If you stop, you keep everything built — it's all in git and documented, and it runs without us. No contract to escape.
Where we'd begin
Week one is a working session on your data: agree the questions, get the slice, and stand up the repo and the model gateway. Give us a data slice and the three questions, and you'll have a working demo in front of you within ~3–4 weeks — then we grow from there, one proven agent at a time. (Commercial terms are in the accompanying proposal.)
LA Digital · Where It Goes
The Agent Roadmap
Your Experiment 2 agents, in the order we'd bring them onto the platform. Deliberately no dates: each is unlocked by the one before it proving its number, so the sequence is a set of decisions you make on evidence — not a fixed timeline to commit to up front. Read-and-advise agents come first; anything that touches money, leases, or government filings comes later, behind the human sign-off gates you already specified.
1
Reporting agentREAD-ONLY · THE WEDGE
Leadership questions answered as charts in a board-ready report. Lowest-stakes, highest-visibility — it proves the platform and earns the right to everything after it.
2
Sales & LeasingREAD & ADVISE
Enquiry response, pipeline reporting, and lease-proposal / LOI drafts prepared for a person to send. Mostly read-and-advise — it surfaces and drafts, the team still decides.
3
FinanceREAD → ACTION · GATED
Starts on the read side — month-end reporting and reconciliation. Then invoicing and reconciliation actions, every commitment over AED 50K behind a human sign-off.
4
Admin & GROREAD → ACTION · GATED
Document management and visa / licence / Ejari expiry tracking with alerts first. Then government-portal submissions — always behind a person, never auto-filed.
5
Development & ProjectsACTION · GATED
Construction-programme monitoring, payment-certificate processing, and FM SLA alerts — the action steps gated behind the same human approvals.
6
OrchestratorCAPSTONE
Only makes sense once there's a network to orchestrate: routes work between the agents and assembles the monthly board pack across all of them.
7
CEO InterfaceCAPSTONE
Sits on top of the matured network: the daily briefing, an approval queue with full context, and scenario modelling on demand — the single pane your doc puts at Phase 1, delivered last because it depends on everything beneath it.
We don't cost these here. Each is sequenced and priced as your priorities sharpen and the previous one proves out — which is the whole point of building it this way rather than buying a fixed multi-agent programme up front.
LA Digital · Reference
Decisions & Confirmations
Everything decided, proposed, or still needed from you — in one place, so how we go about this is never buried in prose. Each decision carries a status; the open items and every "confirm" marker in this document are gathered into the checklist at the bottom.
Decided committed / inherent to the approachProposed our recommendation, a call we make togetherOpen needs your input before we rely on it
What this covers
This register is the how, not the what: Experiment 2 — the seven-agent network, the sequencing logic, the sign-off gates — is your design and unchanged. The decisions below are how LA Digital turns it into something buildable from week one.
Decision register
ID
Decision
Status
Why
AD-01
Start with a read-only reporting agent as agent one.
Proposed
Lowest-stakes (internal data), highest-visibility (leadership sees it weekly); StayAhead gives a head start. A sequencing call made together, not a change to your plan.
AD-02
Build the shared platform and agent one from day one (two tracks).
Decided
The platform is the leverage — built once, every later agent is quick to stand up.
AD-03
v1 runs API-first on Claude (zero-retention); on-prem inference later, on proof.
Proposed
Fastest path to a working result with no upfront GPU spend; prove value before the hardware bet.
AD-04
Every model sits behind a gateway — swap LLM by config, no rebuild.
Decided
Portability and cost control; move any task on- or off-prem without a rebuild. No provider lock-in.
AD-05
Build against a data slice now; repoint to the live MCP-on-Oracle interface when it lands.
Decided
Oracle is mid-standardisation — we don't wait for the whole programme to start.
AD-06
Data sensitivity classified with you; confidential fields are gateway-blocked from external APIs until on-prem is live.
Decided
Residency of storage ≠ residency of processing. Enforced at the gateway, not just on paper.
AD-07
Keep your human-in-the-loop gates: ≥ AED 50K, legal commitments and government submissions always require sign-off; action agents are later phases.
Decided
Read-and-advise first; money, leases and filings stay behind a person. (See the gates matrix below.)
AD-08
Access via Microsoft Entra ID SSO, mapped to your existing groups.
Proposed
No second user directory to maintain. Needs an IT contact to wire up.
AD-09
You own your build (connectors, templates, workflows, tuned prompts); LA Digital retains the reusable framework.
Decided
No per-entity licence, nothing held over you — it's all in git and runs without us.
AD-10
Rolling monthly engagement, 30 days' notice either way, at a ~2-day-a-week cadence.
Proposed
No lock-in; we quote elapsed weeks at real engineer-time. Commercial terms sit in the proposal.
AD-11
Roadmap has no fixed dates — each agent is unlocked by the previous one proving its number.
Decided
The sequence is decided on evidence, not committed up front.
AD-12
Success is measured against baselines agreed in week one.
Decided
Measured, not asserted — so the result is defensible to the board.
Human-in-the-loop gates
Your sign-off rules as a reference grid (AD-07). Read-and-advise first; anything touching money, leases or filings stays behind a person — exactly as you specified.
Action
Agent autonomy
Human sign-off
Phase
Leadership reporting & analysis
Full — reads, never writes
None — advisory
v1 · now
Draft external comms / proposals
Drafts only
Staff review before anything sends
Later
Financial commitment < AED 50K
Prepares & routes
Finance approver [confirm role]
Later
Financial commitment ≥ AED 50K
Prepares only
Always — CEO / CFO [confirm]
Later
Legal commitments / lease execution
Prepares only
Always — authorised signatory
Later
Government / regulatory submissions
Prepares only
Always — responsible officer
Later
Data gateSeparate from the action gates above: a field tagged confidential cannot reach an external API — it is redacted or held back until on-prem inference is live (AD-06). The full data-sensitivity tiers are in the Our Approach tab.
What we need you to confirm
The open items above and every [confirm] marker in this document, gathered with an owner and timing. Most land in week one.
Ref
Item
Owner
By when
AD-01
Named sponsor confirmed (Anuj) + the go-ahead on starting with reporting.
ALMARKAZ
Kickoff
AD-01
The three leadership questions to answer first.
ALMARKAZ leadership
Week one
AD-05
A data slice / extract + a named data owner.
ALMARKAZ
Week one
AD-05
Oracle integrator contact for read-only views & least-privilege access.
ALMARKAZ IT / integrator
Before clean access
AD-08
IT contact for the Entra SSO setup.
ALMARKAZ IT
Platform setup
AD-07
Approver roles for each gate — who signs off ≥ AED 50K, legal, government.
Named backup engineer (continuity behind the embedded engineer).
LA Digital
Kickoff
Unblocks the demoThe first three — sponsor, the three questions, and a data slice — are all it takes to start. Give us those and a working demo is in front of you within ~3–4 weeks. Until then, the platform work (repo, gateway, logging, SSO) needs no data and runs in parallel, so no time is lost.