datastrat builds agent work systems that automate a company's differentiated judgment. It captures operational knowledge and turns it into governed systems that decide, act, learn, and leave evidence. The category is judgment automation: frontier models are available to everyone; a company's operational judgment is not.
Automate differentiated judgment.
Operate decisions inside the company.
Leave evidence for every critical workflow.
"We do not do consulting. We do not bill for reports. We do not sell hours. We build decision infrastructure."
Deep Agents is the conceptual frame. The system is composed of two specialized Deep Agents:
In essential industries, critical decisions are still distributed across documents, spreadsheets, meetings, and tacit judgment.
datastrat solves this by building agent systems that capture operational context, encode business judgment, and turn decisions into executable infrastructure.
datastrat does not prescribe a single solution. Each company picks the model it needs — or both together.
We deploy AI agents to solve critical problems and automate core operations.
Helm · Edges · Atlas
We train your team to lead the transformation from within.
Edges · Helm
Four functional layers assemble around enterprise judgment and are enclosed as an agentic operating system (aOS) — operated by the company's people, connected to operations, and executing real work.
Think of datastrat as decision infrastructure with specialized Deep Agents:
Orchestrates cost, time, contracts, and cash as an operable reality.
Searches, reads, extracts, and cites. If support is insufficient, it says so.
datastrat exists to help organizations make better decisions, faster. Traditional project management tools track what happened, but they don't help you decide what should happen next or simulate alternative futures.
With Antigrid, a project manager can literally chat with their project. Instead of navigating through 10 screens to answer "What happens to our NPV if steel costs increase by 8%?", the manager asks the question in natural language and receives an instant, calculated response backed by the system's own financial models.
"The agent doesn't invent numbers. When it needs real data, it queries. When it needs calculations, it computes using the same formulas as the UI."
Reduces analysis time from hours to seconds. No navigating through multiple screens to answer a single question.
Enables reproducible What‑If scenarios. Test hypotheses without fear of breaking production data.
Uses the same rules and calculations as the rest of the system. No spreadsheet drift or formula errors.
Every decision, every calculation, every scenario is logged and auditable. Full evidence lineage.
A scenario is a logical copy or change layer applied on top of the base model. It allows users and agents to explore "what if?" questions without modifying the production state.
The real, current state of your project. This is the source of truth stored in the database. It represents "what is" right now.
A hypothetical variant (OPT, PES, custom) where you apply changes—cost adjustments, schedule shifts, revenue modifications—to see the impact.
The key insight: scenarios let you test hypotheses and make decisions without risk to production data. It's "Git branching" for project finance.
The Agent Service is a microservice that enables conversational interaction with Antigrid. It can execute controlled actions over your data (APU, budget, schedule, revenue, financial KPIs) to accelerate analysis and simulations—without requiring users to manually navigate the UI.
In practical terms, the agent enables three core capabilities:
Retrieve summaries, lists, and comparisons from the project/budget/model. Ask questions like "What are the top 10 budget items by cost?" or "Show me all APUs using steel."
Compute APU totals, budget rollups, AIU/IDC, cash flows, NPV, IRR, DSCR, and other KPIs using the system's native logic. The agent uses the same calculation engine as the UI.
Create scenarios, apply parameter changes, recalculate the model, and compare impact against the base case—all without modifying production data.
Tools are named functions that the agent can invoke. Think of them as internal endpoints with a stable contract. There are several types:
This ensures the agent never invents data: when it needs real numbers, it queries; when it needs calculations, it computes using the system's native formulas.
The following diagram outlines the high-level request flow between the Frontend, Backend services (Auth, Core, Business), and the AI Agent Service.
+-----------------------------------------------------------------------------------+
| FRONTEND |
| React 19 + TypeScript |
| Port: 10001 |
+-----------------------------------------------------------------------------------+
| | | |
| REST /api/v1 | REST /api/v1 | REST /api/v1 | WebSocket
v v v v
+---------------+ +----------------+ +----------------+ +------------------+
| BACKEND | | BACKEND | | BACKEND | | AGENT SERVICE |
| AUTH (M1) | | CORE (M2-M6) | | BUSINESS (M7-8)| | (M5.1) |
+---------------+ +----------------+ +----------------+ +------------------+
| | | | | | | |
| - Login/JWT | | M2: Catalogs | | M7: Revenue | | - AI Chat |
| - Tenant | | M3: Projects | | M8: Financial | | - 48 Tools |
| - Users | | M4: APU | | | | - Scenarios |
| - Roles | | M5: Budget | | | | - What-If |
| | | M6: Schedule | | | | |
+---------------+ +----------------+ +----------------+ +------------------+
| | | |
+-------------------+--------------------+--------------------+
|
v
+-----------------------------------------------------------------------------------+
| POSTGRESQL 15 |
| Port: 10002 | RLS Multi-Tenant |
+-----------------------------------------------------------------------------------+
|
v
+-----------------------------------------------------------------------------------+
| REDIS |
| Port: 10004 | Cache + Sessions |
+-----------------------------------------------------------------------------------+Domain entities are organized into three distinct phases: Foundations (Auth/Catalogs), Business Core (Projects/Budgets), and Extensions (Schedule/Financials).
╔═══════════════════════════════════════════════════════════════════════════════════╗ ║ PHASE 1: FOUNDATIONS ║ ╠═══════════════════════════════════════════════════════════════════════════════════╣ ║ ║ ║ ┌─────────────────────────────┐ ┌─────────────────────────────────────────┐ ║ ║ │ M1: AUTH + TENANT │ │ M2: CATALOGS │ ║ ║ │ ───────────────── │ │ ─────────── │ ║ ║ │ • tenant │ │ • material │ ║ ║ │ • user │ │ • labor │ ║ ║ │ • user_tenant │ │ • equipment │ ║ ║ │ • role │ │ • transport │ ║ ║ │ • permissions │ │ • input_category │ ║ ║ │ • session │ │ • regional_price │ ║ ║ └─────────────────────────────┘ └─────────────────────────────────────────┘ ║ ╠═══════════════════════════════════════════════════════════════════════════════════╣ ║ PHASE 2: BUSINESS CORE ║ ╠═══════════════════════════════════════════════════════════════════════════════════╣ ║ ║ ║ ┌─────────────────────────────┐ ┌─────────────────────────────────────────┐ ║ ║ │ M3: PROJECTS │ │ M4: APU (Unit Price Analysis) │ ║ ║ │ ────────── │ │ ──── │ ║ ║ │ • program │ │ • apu │ ║ ║ │ • macroproject │ │ • project_phase │ ║ ║ │ • project │ │ • apu_input │ ║ ║ │ • project_parameter │ │ • yield │ ║ ║ └─────────────────────────────┘ └─────────────────────────────────────────┘ ║ ║ ┌─────────────────────────────┐ ║ ║ │ M5: BUDGET │ ║ ║ │ ──────────── │ ║ ║ │ • budget │ ║ ║ │ • wbs (Work Breakdown) │ ║ ║ │ • budget_item │ ║ ║ │ • global_cost │ ║ ║ └─────────────────────────────┘ ║ ╠═══════════════════════════════════════════════════════════════════════════════════╣ ║ PHASE 3: EXTENSIONS ║ ╠═══════════════════════════════════════════════════════════════════════════════════╣ ║ ┌─────────────────────────────┐ ┌─────────────────────────────────────────┐ ║ ║ │ M6: SCHEDULE │ │ M8: FINANCIAL │ ║ ║ │ ─────────── │ │ ───────────── │ ║ ║ │ • schedule │ │ • cash_flow │ ║ ║ │ • activity │ │ • npv / irr │ ║ ║ │ • dependency │ │ • financial_indicator │ ║ ║ └─────────────────────────────┘ └─────────────────────────────────────────┘ ║ ╚═══════════════════════════════════════════════════════════════════════════════════╝
PROGRAM (1)
└── MACROPROJECT (N)
└── PROJECT (N) [Access Control Boundary]
└── PHASE (N)
└── BUDGET (N)
└── BUDGET_ITEM (N) [WBS Nodes]
└── APU (1) [Analysis]
└── APU_DETAIL (N) [Resources]
├── Material
├── Equipment
├── Labor
└── TransportWhen operating within this environment, agents must adhere to the following PRIME_DIRECTIVES:
Agents cannot mutate the Source of Truth directly. All changes must be proposed via Scenarios.
Stochastic outputs must be explicitly flagged with confidence intervals. Do not hallucinate deterministic data.
When querying or proposing changes, always verify relationships across the entity hierarchy. Breaking foreign key constraints is forbidden.
All operations must maintain audit trails. Every decision, calculation, or data transformation must be traceable to its origin.
The AI Agent Service provides 48 specialized tools organized into the following categories: