Elasticboard

Elasticboard: From calendar conflicts to verified actions, powered by Agent Builder and Elasticsearch.

Comment

Inspiration

Work today is fragmented across calendars, chat, docs, and tickets. People spend too much time context-switching and not enough time executing. We wanted to build an agent that does more than answer prompts: it should understand real schedule context, surface what matters, and trigger reliable follow-up actions with evidence.

The core idea behind Elasticboard was simple: treat time as operational data. If meetings, conflicts, and priorities are indexed and queryable in Elasticsearch, an agent can reason over them and drive concrete outcomes.

What it does

Elasticboard is a multi-step AI operations board built with Elastic Agent Builder and Elasticsearch.

It:

  • Connects to Google Calendar via OAuth
  • Syncs and indexes real events into Elasticsearch (calendar-events)
  • Lets users ask schedule and planning questions in natural language
  • Renders actionable storyboard cards on a spatial canvas
  • Saves and reloads storyboards from Elasticsearch (saved-storyboards)
  • Executes a reliable action loop by creating conflict follow-up issues in GitHub
  • Verifies the external action and logs it in Elasticsearch (actions-log)
  • Tracks impact metrics (actions run, actions verified, estimated minutes saved)

This turns “what does my day look like?” into “what needs action now, and was it actually done?”

How we built it

We built Elasticboard as a full-stack app with:

  • Frontend: React + Vite + React Flow
  • Backend: Node.js + Express
  • Data layer: Elasticsearch as the primary store
  • Agent runtime: Elastic Agent Builder APIs

Pipeline:

  1. User connects Elastic credentials and integrations from UI.
  2. Backend handles Google OAuth and token lifecycle.
  3. Calendar events are fetched, normalized, and indexed in Elasticsearch.
  4. Agent Builder uses search/ES|QL to reason over indexed context.
  5. Responses are shown in Markdown and converted into storyboard nodes.
  6. User can manually add/edit board structure, then save/load storyboards.
  7. For conflict resolution, backend detects overlap, creates a GitHub issue, verifies it exists, and logs execution in actions-log.
  8. Metrics are computed from the log index and displayed in UI.

Challenges we ran into

  • OAuth friction (redirect_uri_mismatch) and credential consistency across local environments
  • Balancing human-friendly responses with machine-readable node payloads
  • Preventing index mapping conflicts when saving canvas positions (long vs float)
  • Avoiding “demo gimmicks” while still making the UX understandable and smooth
  • Building action reliability: not just calling an API, but verifying and logging outcomes

Accomplishments that we're proud of

  • End-to-end real integration flow (no simulated data paths)
  • Multi-step agent behavior with retrieval, reasoning, and tool execution
  • Verified external action loop (GitHub issue creation + verification + audit log)
  • Elasticsearch used as system of record for events, boards, and action telemetry
  • Practical UI that supports both automation and manual control
  • Clear path from insight to execution, with measurable impact

What we learned

  • Reliable agents need state, not just prompts.
  • Tool orchestration quality matters more than model verbosity.
  • Retrieval design (index schema + query strategy) directly impacts agent usefulness.
  • Verification and observability are essential if agents are expected to take action safely.
  • UX details (rendering, editing, saving, loading) are what make an agent feel production-ready.

What's next for Elasticboard

  • Add more action destinations (Slack, Jira, email workflows)
  • Introduce approval policies and role-based action guards
  • Add recurring automation for daily/weekly conflict triage
  • Expand impact analytics (resolution latency, conflict recurrence, decision quality)
  • Support multi-agent collaboration (planner, executor, verifier roles)
  • Package reusable templates for domain-specific operating boards (sales, engineering, support)
Share this project:

Updates