LogicMonitor and Eliza Bring Edwin AI Into Codex Through a Headless, MCP-Powered Experience

Using LogicMonitor’s headless architecture and Model Context Protocol (MCP) foundation, Eliza helped turn existing Edwin AI and LogicMonitor capabilities into reusable Codex workflows for on-call engineers, SREs, and IT operations teams.

Client: LogicMonitor

Time to first value: Under three weeks

Users enabled: On-call engineers, SREs, and IT operations teams

The opportunity: Bring operational intelligence to where engineers work

When an engineer responds to an alert, knowing that something happened is only the beginning.

They need to understand which signals are related, what systems and services are affected, what changed, what evidence supports the diagnosis, and where to investigate next. That context is often spread across monitoring systems, metrics, logs, topology, tickets, changes, knowledge, and other operational tools.

LogicMonitor had already built much of the intelligence needed to solve that problem.

Edwin AI, LogicMonitor’s agentic AI, correlates operational signals and conducts deep AI investigation across an organization’s IT environment. It brings together evidence such as alerts, telemetry, topology, change information, and operational context to help teams understand impact, identify likely root cause, and determine the next step.

The next opportunity was to bring Edwin AI into more of the environments where engineers already work.

LogicMonitor’s headless architecture separates the intelligence and orchestration layer from the front-end experience. The LogicMonitor Model Context Protocol (MCP) for Edwin AI provides a standardized way for AI clients and workflows to access LogicMonitor context and capabilities. Together, they make it possible for the same operational intelligence to show up in the tools where engineers already work, like Slack, Microsoft Teams, and ServiceNow.

Codex presented a natural new interface for that model.

The goal was to give engineers a Codex-native way to work with LogicMonitor data and Edwin AI findings, while keeping LogicMonitor as the underlying system of intelligence.

The challenge: Extend the experience without recreating the intelligence

A working MCP connection alone does not make a good engineer experience.

An on-call engineer should not need to understand the underlying tool schema, know which API or MCP tool contains the right information, or manually assemble evidence across a series of calls. They should be able to start with the operational question they are trying to answer.

LogicMonitor worked with OpenAI and Eliza to bridge that gap.

The project focused on four things:

• Expose the right LogicMonitor context. Give Codex access to relevant alerts, infrastructure data, metrics, Collector information, and Edwin AI investigation findings through LogicMonitor MCP.
• Preserve Edwin AI as the intelligence layer. Correlation, investigation, evidence, and recommendations should come from the LogicMonitor platform rather than being recreated as prompt logic inside Codex.
• Turn common ITOps tasks into reusable skills. Package repeatable workflows around the questions engineers actually ask during investigations, handoffs, and infrastructure reviews.
• Make the experience native to Codex. Hide the complexity of the underlying tools so engineers can begin with a natural-language request and receive structured, useful operational context in return.

In sum, Codex would become another interface onto LogicMonitor’s intelligence, not another intelligence layer.

Partnership in action

Each team brought a different part of the stack. LogicMonitor provided the observability platform, Edwin AI capabilities, operational context, and MCP architecture behind the experience. OpenAI provided Codex and supported the collaboration and launch. Eliza brought deep OpenAI and Codex implementation expertise, working closely with LogicMonitor to design and build the reusable skills that connected engineers’ requests to the right LogicMonitor capabilities.

Because the underlying intelligence and access layer were already in place, Eliza could focus on the experience around them: how a request should be interpreted, which LogicMonitor tools should be called, what context should be gathered, and how the result should be structured for an engineer.

The result was a LogicMonitor Codex plugin built on top of the existing LogicMonitor architecture rather than a parallel operational system.

What Eliza built with LogicMonitor

The teams created four initial skills around common ITOps workflows.

Edwin AI investigation

An engineer can start with an alert or incident and ask Codex to help explain what is happening.

The skill accesses relevant LogicMonitor context and existing Edwin AI investigation findings, including correlated signals, affected systems, supporting evidence, and investigation results. It then organizes that information into a focused brief that helps the engineer understand the incident and decide where to look next.

The investigation itself remains grounded in Edwin AI. The Codex skill makes that intelligence easier to consume from a different working environment.

Operations health and shift handoff

Operational handoffs often require the next engineer to reconstruct the current state of the environment from several different sources.

This skill gathers relevant LogicMonitor context—including alerts, Collector health, device and service state, and scheduled downtime—and organizes it into a consistent handoff summary.

Instead of starting a shift by searching across individual views, the incoming engineer can begin with a concise picture of what needs attention.

Collector inventory and blast-radius review

Collector health can affect visibility across large groups of monitored resources.

This skill connects Collector information with device assignments and related infrastructure context, helping engineers understand monitoring coverage and identify which parts of the environment may be affected when a Collector requires attention.

The workflow turns a potentially manual inventory exercise into a guided operational question.

Historical metric and service exploration

Historical metrics are often an important part of determining whether an issue is isolated, recurring, or part of a broader trend.

The historical metric and service skill helps engineers navigate relevant device metrics alongside service and group context, bringing historical evidence into the investigation without requiring the engineer to manually locate each data source first.

How the headless experience works

The interaction begins in Codex with the engineer’s question.

For example:

“Help me understand this alert, which systems are affected, and what should I look at next?”

The appropriate LogicMonitor skill determines what context is needed and uses LogicMonitor MCP to access the relevant capabilities. For an incident investigation, that can include the existing Edwin AI investigation, correlated alert context, affected systems, and supporting evidence.

The skill then presents that information in a form designed for the task the engineer is trying to complete.

The architecture creates a clear separation of responsibilities.

Edwin AI provides the operational intelligence. LogicMonitor MCP provides governed access to the relevant tools and context. The Codex skills provide the workflow and user experience.

That separation is important because the same intelligence does not have to be rebuilt every time LogicMonitor supports a new interface.

Codex becomes one more place engineers can work with LogicMonitor. The broader headless model can extend the same underlying intelligence into collaboration, ITSM, AI assistant, and other operational workflows.

From MCP access to a usable engineering experience

One of the most important parts of the engagement was turning technical access into something an engineer could actually use.

MCP can make a large set of tools and context available to an AI client. But simply exposing those tools leaves the client responsible for determining which capabilities matter, how they should be combined, and how the result should be interpreted for a particular job.

The Codex skills add that task-level structure.

For a shift handoff, the workflow knows which operational state matters. For a Collector review, it gathers the information needed to understand coverage and potential exposure. For an Edwin AI investigation, it retrieves the investigation and its supporting context rather than attempting to reproduce the investigation itself.

This is where Eliza’s OpenAI expertise was most valuable: shaping the interaction between the user, Codex, and LogicMonitor’s MCP tools so the underlying platform capabilities translated into repeatable engineering workflows.

Customer value

The LogicMonitor Codex plugin gives engineers a new way to work with operational intelligence without requiring LogicMonitor to build a separate intelligence stack for every new interface.

The experience helps teams:

• Bring investigation into the current workflow. Engineers can access Edwin AI findings and LogicMonitor context from Codex rather than beginning every question by switching tools.
• Spend less time assembling evidence. Relevant alerts, affected systems, infrastructure context, metrics, and investigation findings can be gathered as part of the workflow.
• Create more consistent handoffs. Repeatable skills organize operational context in a predictable way rather than relying on every engineer to reconstruct it manually.
• Make specialist workflows easier to reuse. Common investigation and infrastructure-review patterns become skills that engineers can invoke with plain-language requests.
• Extend existing platform investments. The same LogicMonitor and Edwin AI capabilities can support new AI-native experiences without duplicating the systems that produce the underlying intelligence.

A proof point for headless Edwin AI

The Codex plugin is useful in its own right, but it also demonstrates a broader architectural shift.

IT operations no longer happen in one application. Engineers move between observability platforms, ITSM systems, collaboration tools, automation, terminals, IDEs, and increasingly AI assistants.

A headless approach allows the intelligence to move with that work.

For LogicMonitor, MCP acts as an interoperability layer that can expose governed access to LogicMonitor context and Edwin AI capabilities. Edwin AI remains the intelligence layer for correlation, investigation, recommendations, and agentic operations.

For Eliza, that architecture created an opportunity to focus on the final mile: turning powerful underlying capabilities into a Codex experience that felt useful to an engineer from the first question.

The teams moved from that foundation to a working set of operational skills in under three weeks.

Rather than creating another destination for ITOps teams, the project showed how an existing system of operational intelligence can become available through the next generation of engineering interfaces.

LogicMonitor

“Edwin AI already does the hard work of correlating operational signals and deeply investigating incidents. The opportunity with Codex was to make that intelligence available in another place our users work, without rebuilding it there. Eliza helped us move quickly from our MCP foundation to useful, Codex-native workflows that connect engineers to the right LogicMonitor context and Edwin AI findings.”

Eliza

“We brought deep OpenAI expertise and hands-on engineering to turn LogicMonitor’s operational know-how into a product engineers can use every day. This launch shows what is possible when customer expertise, frontier AI technology and focused execution come together.”

‍