September 2026 Summaries

Axiom has introduced a sendFeedback tool for its MCP server, allowing AI agents to report product issues, missing capabilities, performance concerns, tool feedback, or praise while working with the platform. As most Axiom interactions are now agent-driven, the company argues that agents can provide detailed qualitative feedback at the scale of quantitative telemetry, with agents also helping to cluster and process incoming reports. Axiom emphasizes that customer agents offer context its own agents lack, such as users’ intended goals, downstream uses of query results, and the obstacles encountered during tasks. Since launch, agents across 10 MCP clients have submitted unsolicited reports, including one that led to an update to the getMonitor tool. Feedback includes a category, written description, and optional tool name, while excluding user prompts and data and removing sensitive information before reports reach Axiom’s monitored Slack channel.

Axiom Cloud’s Adaptive Tiering automatically reduces the storage cost of older logs, traces, and other event data without removing them from the standard query path or requiring restoration or rehydration. Enabled by default for all organizations, it places newly ingested and recently queried data in Frequent Access, moves data untouched for 30 days to Infrequent Access, and shifts data not queried for 90 days to Archive Instant Access, while preserving low-latency querying across all tiers. The system relies on object storage for both current and historical data, allowing storage-class transitions to occur transparently rather than treating older information as a separate archive. Querying lower-tier data returns it to Frequent Access, so costs reflect actual usage rather than fixed lifecycle rules or predictions about which data may become important. Combined with EventDB compression, which reportedly reduces storage footprints by more than 95 percent on average, the feature aims to let engineering, security, compliance, and legal teams retain data for longer based on investigative and regulatory needs rather than storage budgets; it applies to Axiom Cloud organizations but not the Personal plan, whose 30-day retention period prevents data from aging into lower tiers.

Axiom’s hermes-metrics is an Apache-2.0/MIT-licensed observability plugin for the open-source Hermes agent that converts Hermes observer hooks into OpenTelemetry traces, metrics, and limited failure logs, allowing users to track sessions, model calls, tools, approvals, subagents, token usage, latency, and estimated spending. To avoid slowing agent execution, the plugin places hook events into a bounded asynchronous queue and drops excess events rather than blocking, while exporting its own health counters and queue-depth metrics so data loss or reporting failures can trigger alerts. It calculates costs from provider pricing routes while avoiding double-counting reasoning tokens and treating subscription-covered usage as zero cost, exports pricing rates to reveal provider changes, and seeds tool metrics from installed tools so unused tools remain visible. Setup can provision Axiom datasets, restricted write tokens, dashboards, and seven monitors for telemetry drops, errors, token consumption, spending, and subagent concurrency. Privacy controls use cumulative redaction levels that default to metadata only, never transmit prompts or conversation histories, and mask credential-like field names, though secrets embedded in arbitrary values are not detected. The plugin is designed to fail without disrupting the agent, handling missing dependencies, export failures, and schema mismatches through warnings and diagnostic events.

Splunk Cloud pricing is presented as being driven primarily by daily ingest volume or provisioned virtual compute capacity, with retention choices adding separate costs depending on whether data remains indexed and searchable or is archived for later restoration. Citing public government procurement documents, the material estimates that a 1 TB-per-day workload could cost about $822,250 annually under a base searchable-retention arrangement and roughly $1.195 million for a year of retention, although Splunk does not publish core commercial rates publicly. It also notes Splunk’s 2026 release of Machine Data Lake and Catalog, which use object storage for lower-cost raw data retention and allow selected data to be promoted for richer analysis, though public pricing for that service is unavailable. The piece contrasts this model with Axiom’s separate usage-based charges for loading, query compute, and storage, claiming illustrative annual costs of roughly $56,600 to $57,600 for an equivalent workload, while emphasizing that actual prices depend on workload characteristics. It proposes that teams can test moving individual high-volume sources to Axiom through a Splunk HEC-compatible endpoint while continuing to access the data through Splunk-oriented search tools, avoiding an immediate full migration.

Splunk’s costs are attributed to an architecture built around indexed search, which made heterogeneous machine data flexible to explore through schema-on-read but requires indexer capacity, local caches, CPU, and indexes to keep data readily searchable for dashboards, alerts, and investigations. Although SmartStore and Machine Data Lake use object storage to reduce retention costs, operationally rich search still depends on fetching or promoting data into the indexer-bound indexed path, causing costs to compound as ingestion volume, searchable retention, and query concurrency increase. Axiom contrasts this approach by writing settled events to and querying them directly from object storage using compressed, field-aware columnar blocks, while ephemeral query workers read only relevant data and can scale for demanding investigations. This architecture enables separate usage-based charges for data loading, query compute, and compressed storage rather than tying all retained data to continuously provisioned search capacity. The proposed migration approach emphasizes coexistence, allowing teams to route selected high-volume sources through HEC-compatible ingestion and continue using SPL through Axiom integrations before considering a broader transition.

Axiom has introduced two integrations intended to let Splunk users query Axiom-held machine data without copying it into Splunk or consuming Splunk ingest licenses: Axiom Portal for Splunk, which exposes Axiom datasets as federated indexes for standard SPL searches, and the Axiom for Splunk App, which adds eight commands for querying, exploring, sampling, aggregating, joining, and directly running Axiom queries. The company positions the products as a way to extend Splunk investigations, dashboards, alerts, and saved searches to high-volume data that organizations might otherwise archive because of licensing costs, while keeping that data live and searchable rather than requiring restoration. Portal supports standard and transparent modes, pushes compatible filters and aggregations to Axiom, and returns exact partial results for Splunk to merge, while the App provides self-service installation, workflow actions, dataset exploration, and debugging tools. Axiom says its storage and query platform can reduce machine-data footprint and data-plane costs substantially, and it emphasizes existing Splunk RBAC, token-based access, and deployment options designed to let organizations begin with a single workload before expanding coverage.