Core domain digest
Agent workspaces become a distinct storage tier
- AI
- Cloud Architecture
- Enterprise IT Architecture
What happened: Google Cloud introduced Filestore agent volumes for GKE agent sandboxes. The service dynamically allocates an isolated persistent workspace for each task, supports rapid detach and resume, applies per-workspace access boundaries, and can expose one ReadWriteMany workspace to collaborating agents with POSIX locking. It is broadly available for non-production use, while production availability is allowlisted.
Why it matters: Agent platforms need more than ephemeral compute. Long-running work, human approval pauses, package installation, code generation, and multi-agent collaboration all create state that must survive a sandbox without becoming shared by accident.
Enterprise adoption impact: Platform teams can stop building custom copy-in and copy-out mechanisms for each agent session. The preview posture still matters: durability, backup, deletion, residency, forensic preservation, and cost behaviour need testing before the workspace becomes a production system of record.
Architecture implication: Model agent state as separate layers: immutable inputs, private scratch space, approved shared artifacts, and retained evidence. Workspace identity and lifecycle should follow the task and policy, not merely the pod.
Watchpoint: Test suspension and resume, cross-agent write conflicts, tenant isolation, deletion guarantees, backup, sensitive-file scanning, and what survives a failed or cancelled task.
S3 data gains consistent file access across ECS compute modes
- Cloud Architecture
- Enterprise Integration
- AI
What happened: Amazon ECS added S3 Files support for tasks using the EC2 launch type, completing support across EC2, Fargate, and ECS Managed Instances. Containers can mount existing S3 data through standard file-system operations without copying or staging it first; the service uses Amazon EFS to provide the shared file layer.
Why it matters: File-oriented applications and agents can operate on governed object data with less adaptation. That removes integration plumbing, but it also makes an apparently local file operation capable of changing durable shared data.
Enterprise adoption impact: Migration and batch workloads can reuse existing tools, and teams can move between ECS compute models with a more consistent storage contract. Performance, concurrency, object-to-file semantics, and write behaviour still need workload-specific validation.
Architecture implication: Keep S3 as the authoritative data boundary. Apply least-privilege task roles, separate read and write mounts, define atomicity and recovery expectations, and emit data-change evidence independently of application logs.
Watchpoint: Benchmark one representative workload for latency, rename and overwrite behaviour, concurrent access, access-point policy, failure recovery, and the cost of the EFS-backed layer.
Kong upgrades require policy and MCP regression tests
- API Management
- Enterprise Integration
- Event-Driven Architecture
- AI
What happened: Kong Gateway 3.16 replaced its Common Expression Language implementation with a specification-compliant backend, creating a documented compatibility break for some quote escaping and missing-map-key expressions. The release also added transparent decompression for several Kafka record-batch formats. A 3.15 maintenance release fixed MCP proxy failures involving forwarded HTTPS ports and compressed or malformed request bodies, alongside AI guardrail and token-accounting fixes.
Why it matters: Gateway policy is executable architecture. A standards-correct engine can still change production authorization outcomes, while small transport-handling defects can surface as rejected or misrouted tool calls far from the agent that initiated them.
Enterprise adoption impact: Teams gain better Kafka interoperability and important MCP reliability fixes, but a routine gateway upgrade now needs policy-semantic and agent-traffic regression coverage, not only throughput and availability checks.
Architecture implication: Version gateway policy fixtures with expected allow, deny, and error outcomes. Include real MCP transport variations, Kafka compression, null provider fields, and reasoning-token accounting in the release test pack.
Watchpoint: Replay production-derived CEL expressions and MCP requests in a shadow environment, focusing on missing context values, escaped strings, non-default TLS ports, gzip bodies, and malformed requests.
OpenTelemetry migration succeeds by preserving the producer contract
- Observability
- Cloud Architecture
- Enterprise IT Architecture
What happened: Atlassian described replacing a StatsD-based metrics pipeline serving roughly 100,000 hosts across 14 regions with purpose-built OpenTelemetry Collector distributions. The platform kept the existing StatsD producer interface while changing collection, ingest, aggregation, and forwarding behind it, then added OTLP alongside the legacy path. The reported design reduces sidecar and aggregation overhead while opening a gradual route to native OpenTelemetry instrumentation.
Why it matters: The useful lesson is migration shape, not company scale. Preserving the producer contract keeps application teams off the critical path and lets the platform team change internals progressively while old and new telemetry coexist.
Enterprise adoption impact: Organizations can pursue OpenTelemetry without demanding an immediate estate-wide SDK rewrite. Dual operation still introduces parity, routing, cardinality, and rollback work that must be explicitly funded.
Architecture implication: Treat telemetry ingestion as a stable interface. Decompose the pipeline into independently replaceable stages, preserve operational workflows, profile in production, and move low-risk traffic through progressive rollout gates.
Watchpoint: Pilot a collector replacement behind an unchanged endpoint, then compare loss, aggregation, shard balance, alert parity, resource use, and rollback time before asking services to change instrumentation.
Local Belgian/Flemish enterprise IT watch
APK Group adds in-house network and data-centre delivery capacity
- Local Market
- Cloud Architecture
- Enterprise IT Architecture
What happened and when: On 16 September, APK Group announced the acquisition of Tongeren-based GITS, adding about 30 employees working on data cabling, server rooms, camera systems, access control, and related building infrastructure. GITS had already worked as a subcontractor for roughly two and a half years and will continue as a separate business unit.
Why it signals market movement: The buyer is converting an established subcontracting relationship into owned capacity and explicitly targets complex environments such as data centres, airports, and large enterprise buildings. This is a focused capability expansion rather than a broad branding partnership.
Consulting and delivery impact: Local clients may encounter more bundled offers spanning physical connectivity, building security, smart applications, and supporting IT services. Architecture conversations should connect logical cloud and edge designs to cabling, access-control, segmentation, monitoring, and operational ownership earlier in the programme.
Confidence and limits: Confidence is high that the transaction and staffing move occurred because both the company announcement and independent Belgian trade coverage align. Financial terms, integration targets, and the future service mix were not disclosed, so the commercial impact remains uncertain.
Watchpoint: Watch whether the new unit expands beyond installation capacity into integrated data-centre, edge, security, and managed-network services, and whether larger Belgian projects begin to combine these scopes in one procurement.