Obligation Agent

Inspiration

Organizations make thousands of commitments every day, but most of them are not created inside a task-management system. They happen naturally in Slack messages, emails, meetings, project discussions, and issue trackers.

A simple statement like “I’ll send the final proposal to Sarah by Friday” creates an obligation, but the organization then has to manually track who owns it, whether progress is being made, what is blocking it, what depends on it, and whether the promised outcome actually happened.

We wanted to build a system that could understand these commitments from the existing flow of work instead of forcing people to manually record everything.

That idea became Obligation Agent: an intelligence layer that continuously observes organizational work and turns scattered signals into structured, explainable, and actionable obligations.

What it does

Obligation Agent continuously answers:

Who owes what?
To whom?
By when?
What does it depend on?
What evidence suggests progress or completion?
What is at risk?
Why is it at risk?
What should happen next?

The system ingests signals from connected work platforms such as Slack, Gmail, Google Calendar, and Jira Cloud.

It uses natural-language intelligence with Google Gemini to interpret commitments, progress updates, blockers, completion signals, and contextual information. It then connects these signals to obligations, evidence, dependencies, reconciliation, risk analysis, root-cause reasoning, and decision intelligence.

The system does not simply mark something as “done” because an AI model or external system says so. External events and AI outputs are treated as untrusted observations or proposals. Consequential actions remain behind validation and explicit human authorization.

How we built it

We built Obligation Agent as a provider-agnostic, event-driven platform.

At the ingestion layer, external signals are normalized into a common event model and placed into a durable event inbox. This provides deduplication, idempotency, asynchronous processing, retries, dead-letter handling, and traceability.

Above that sits the intelligence layer, which combines deterministic domain logic with Gemini-based natural-language interpretation. The system can extract obligations, interpret semantic events, reconcile conflicting observations, analyze dependencies, predict risk, identify root causes, and generate grounded recommendations.

A controlled decision and execution layer sits after the intelligence layer. AI can recommend an action, but it cannot independently execute consequential operations.

We also built supporting capabilities for:

Multi-tenant workspace isolation and RBAC
Evidence and provenance tracking
Operational audit and trace reconstruction
Provider health and failure isolation
CSV import with validation and templates
Demo data seeding and mock intelligence
Slack, Gmail, Google Calendar, and Jira Cloud integrations
Production-oriented workers, retries, monitoring, and security controls

The backend is built around the existing service/domain architecture, while the frontend provides dashboards and management interfaces for obligations, intelligence, integrations, reconciliation, activity, decisions, and operational audit.

Challenges we ran into

The hardest part was not simply connecting an LLM.

The real challenge was building a system where information from different sources could be trusted, correlated, and acted upon without allowing automation to create dangerous assumptions.

We had to solve problems such as:

Normalizing very different provider events into one consistent event model
Handling duplicate, delayed, malformed, or conflicting external events
Connecting evidence across multiple systems
Preserving strict tenant isolation
Preventing LLM outputs from becoming unauthorized system actions
Building durable asynchronous processing rather than relying on fragile synchronous flows
Making AI useful while still grounding it in actual organizational data
Designing realistic demo data and test scenarios
Debugging real-world issues such as invitation flows, CSV imports, data loading, and integration management

One of the biggest lessons was that reliability and security have to be part of the architecture from the beginning, rather than something added after the intelligence layer is finished.

Accomplishments that we're proud of

We are proud that Obligation Agent evolved from an idea about “AI task tracking” into a complete organizational obligation intelligence system.

Some of the accomplishments we are particularly proud of are:

A full obligation lifecycle from discovery through verification
Multi-source event ingestion with durable asynchronous processing
Dependency graphs, risk analysis, root-cause reasoning, and critical-path analysis
Human-controlled decision execution rather than autonomous AI actions
Gemini integration through a provider abstraction
Real Jira Cloud integration using the same event architecture as other providers
Strong multi-tenant isolation and authorization boundaries
Immutable operational audit and traceability
Evidence and reconciliation across conflicting observations
A repeatable demo environment with realistic seeded organizational data

The system also reached a strong level of automated validation, including hundreds of backend tests, security checks, production-readiness checks, and frontend build/lint validation.

What we learned

The biggest lesson was that organizational intelligence is much harder than simply extracting information from text.

An obligation is not just a sentence. It is a relationship between people, outcomes, deadlines, dependencies, evidence, and changing real-world state.

We learned that:

Context matters. The same sentence can mean very different things depending on surrounding events and dependencies.
Multiple sources are better than one source. A Slack message, Jira status, calendar event, and evidence record may each tell only part of the story.
AI needs boundaries. LLMs are excellent at interpretation and reasoning, but they should not become the source of authorization or truth by themselves.
Reliability is part of intelligence. An intelligent system that loses events, duplicates actions, or leaks tenant data is not useful intelligence.
The hardest validation is real-world validation. Passing unit tests is necessary, but actually using the system exposed issues that architecture diagrams never would.

What's next for Obligation Agent

The next stage is moving beyond implementation into broader real-world validation and product refinement.

We want to validate the system with realistic organizational workflows, improve the quality of predictions and recommendations through real feedback, expand provider coverage, and continue refining how obligations are inferred from noisy cross-system signals.

Long term, the vision is for Obligation Agent to become a continuously operating intelligence layer for organizations: one that understands commitments as they emerge, recognizes when they are becoming risky, explains the underlying causes, recommends the right intervention, and verifies what actually happened.

The goal is not to create another place where people manually enter tasks.

The goal is to make organizational commitments observable, understandable, and accountable.