Your Agent. Your Business Needs.
When did you last paste something from work into a private AI chat, just to get a quick answer? The answer looks good, it's fast, and nobody has to know. But now your company's documents sit on someone else's server, and nobody can tell where that answer actually came from.
When we first developed our own agent, we worked out a few practices and found six pillars that decide whether an agent built for a business need is useful in daily work: trusted, contextual, governed, traceable, operational and expandable. They help you design your agent and get your data ready for it. We adapted them from the layers Pramod Sadalage and Prem Chandrasekaran describe for making data ready for agentic AI [1].
And the best way to explain them here? Meet Alex, a new consultant at a travel agency, and her very first customer request.
Of course, Alex, the agency and all numbers here are fictional and don't represent any real people or companies. But please, indulge us in this little play.
Monday Mornings
Alex started at a travel agency in Hamburg a week ago. On her first day with customers, a family of four sits down at her desk and spends two hours describing their holiday: "Four of us, July, somewhere quiet by the sea. No night flights… Ah, and the hotel staff should be nice." When they leave, the work is hers. By Friday she needs flights for four in July and a quiet hotel near the beach, with availability, rates, cancellation and supplier rules checked, an itinerary that stays under 3.000 €, and a quote and an invoice on the family's table.
Her first intuition is to ask an LLM. The agency has no internal or corporate solution for LLM usage, so she opens the private subscription she already pays for. Because she is new and wants the answer to match how the agency works, she pastes some internal documentation into the chat as well. The answer looks useful, but the way she got it is a problem: internal company documents now sit in a private account, outside the agency's control, and nothing in the answer can be traced back to where it came from. Alex's situation is not specific to travel agencies; in the 2024 Work Trend Index by Microsoft and LinkedIn, 78 % of AI users said they bring their own AI tools to work, which, as Microsoft notes, puts company data at risk [2].
Also, the chat stays disconnected from the agency's systems. It has no view of availability in the booking system, no access to the supplier rules and no way to produce a quote or an invoice, and it knows company policy only as far as the pasted documents happen to cover it. The family describes their holiday in terms the agency's internal booking tool offers no filter for, such as "quiet" or "nice staff". What the agency needs is an agent that runs inside the company, with access to its data, its policies and its systems, under rules the company sets.
What does the agent need to accomplish?
What would it take to hand this request to an agent? Its structure has to match the work Alex does. The process taught in the agency's onboarding can be broken down into four patterns. Quoting, booking and invoicing always happen in the same order, so this part of an agent can be a linear sequence in which the model does not decide the order of the steps. Bandara et al. recommend handling steps that need no language reasoning as plain function calls in the orchestration layer, instead of letting the model decide them [3]. Finding an offer under 3.000 € is a loop: Alex searches, checks whether the result fits the budget and the family's wishes, and searches again with adjusted parameters until it does, which in an agent requires a clear condition for when the loop stops. Choosing a supplier and the policy that comes with it is a branching decision that can be modelled as a graph of decision tables, so that an agent follows the agency's rules for each supplier instead of making them up. The search for flights and the search for hotels do not depend on each other and can run in parallel, with one coordinator that collects the results.
%%{init: {"theme": "base", "themeVariables": {"background": "#ffffff", "clusterBkg": "#f2f2f2", "clusterBorder": "#d0d0d0", "primaryColor": "#ffffff", "primaryBorderColor": "#9a9a9a", "primaryTextColor": "#222222", "secondaryColor": "#f2f2f2", "tertiaryColor": "#f2f2f2", "lineColor": "#666666", "edgeLabelBackground": "#ffffff"}}}%%
flowchart TB
subgraph lin["Linear: fixed order"]
direction LR
q("Quote") --> bo("Book") --> inv("Invoice")
end
subgraph lp["Loop: repeat until it fits"]
direction LR
se("Search") --> fi{"Fits?"}
fi -- "no" --> se
fi -- "yes" --> of("Offer")
end
subgraph gr["Graph: branching decisions"]
direction LR
ws{"Which supplier?"} --> pa("Policy A")
ws --> pb("Policy B")
end
subgraph par["Parallel: side by side"]
direction LR
co("Coordinator") --> fl("Flights")
co --> ho("Hotels")
end
lin ~~~ lp ~~~ gr ~~~ parThe diagram could not be rendered — here is its source.
Mapping the process to these building blocks shows where an agent needs data and where it needs rules. The search steps need rates, availability and knowledge about the hotels, the branches need the supplier rules and company policy, and the package step needs access to the booking system to produce a quote and an invoice. So what does the agent need to do this work?
1. Trusted: Garbage in, confident garbage out
Alex asks for the Aurora Bay's rate in July. The Aurora Bay is a beach hotel the agency works with and looks like a good match for the family; an old rate sheet lists it at 214 € a night in July, which was the rate last winter. An agent that is given this sheet repeats the 214 € in its offer, with no hint that the number is outdated, because it has no way of telling current data from old data.
Before an agent can plan anything, it needs data that meets two conditions: the data has to be of high quality, and the agent has to understand its structure and meaning, ideally without direct access to the source systems behind it. The gap between how ready companies consider their data and how ready it is appears to be wide: in the 2026 State of Data Integrity and AI Readiness report by Precisely and Drexel University's LeBow College of Business, 87 % of the more than 500 surveyed data and analytics leaders say they are ready for AI, while 43 % name data readiness as their biggest obstacle [4]; Sadalage and Chandrasekaran refer to the same finding [1].
Let's say the agency works with 600 hotels, and each of them delivers a rate feed with its own rules and structure. How can the expectations the agency has for this data be defined? One option for writing these expectations down is a data contract following the Open Data Contract Standard \[5\], which describes a dataset through its schema, semantics, quality rules and an SLA. The contract is used in two places. The data pipeline runs independently of the agent and uses the quality rules and the SLA to check incoming rates and filter out what fails, so that only valid data reaches the dataset the agent works with. The agent itself queries that dataset and uses the field descriptions in the contract to understand what each value means, without having to inspect the source systems. For the hotel rate feed, the contract looks like this:
schema:
- name: hotel_rates
properties:
- name: hotel_id
logicalType: string
description: supplier hotel id
- name: nightly_rate
logicalType: number
description: Rate for one night, one room, excluding taxes and fees
quality:
- rule: validValues
mustBeBetween: [10, 5000]
- name: hotel_name
logicalType: string
physicalType: varchar(200)
required: true
description: Display name of property.
quality:
- type: sql
description: one rate per hotel, room type, stay date
mustBe: 0
slaProperties:
- property: freshness
value: 24
unit: hWith a freshness SLA of 24 hours, last winter's Aurora Bay rate fails the check, and the same applies to any record that breaks one of the quality rules. The description of nightly_rate tells the agent that taxes and fees are not included in the rate it quotes to the family, without the agent ever having to open the rate table itself.
A contract describes what good data looks like, but it does not stop bad data from arriving. Rate feeds come from supplier APIs, databases and streams, and if the agent reads directly from them, every outdated rate can end up in the family's offer. How can the agency make sure that only checked data reaches the agent? What it needs is a data pipeline with one goal: an agent only ever sees data of high quality that has passed the checks.
One option for this is the medallion architecture, a data design pattern described in the Databricks documentation [6], which Sadalage and Chandrasekaran apply to agentic systems [1]. Data from the source systems first lands in a bronze tier as raw, immutable input that keeps the audit trail and the lineage. Contract verification then checks schema, freshness and quality. Data that passes moves to silver, validated and deduplicated, while data that fails goes to a dead letter queue instead of to the agent. A second step applies certification, business rules and reconciliation before the data reaches gold, and an agent reads only from the gold tier.
The checks come from the data contract. Documents pass through the same tiers, with checks taken from their frontmatter (see pillar 2). That's easy enough for structured data, but what about unstructured data?
2. Contextual: Which hotel has friendly staff?
Alex looks for a hotel with friendly staff, and the booking tool has no field for it; the same is true for the family's other two wishes, quiet and a short way to the beach. Whether the Aurora Bay is loud is documented only in Google reviews and questionnaires. The distance to the beach is relative, since ten minutes on foot differs from ten minutes by bus. What the staff is like is spread across guest emails, feedback forms and scanned PDFs collected over the past years, written in every kind of prose.
The goal for this kind of data is, ideally, a knowledge base that humans and agents can both understand and curate, instead of an agent searching through mailboxes and file shares on its own. How can such a knowledge base be built for data that has no schema and grows every day? One option for this kind of material is retrieval-augmented generation (RAG) over the archive [7]. In recent projects at Posedio, we noticed that the main cost lies in keeping up with change: reviews arrive every day, and every new batch means pre-processing, chunking and re-embedding before the agent can use it. We at Posedio found the Open Knowledge Format (OKF), which Google Cloud published in June 2026 [8], to be a promising option. OKF stores knowledge as a directory of Markdown files with YAML frontmatter; humans can read and edit these files like any other document, and an agent can navigate and read them, which matches the goal of a knowledge base that both can understand and curate.
With OKF, the knowledge base of the travel agency looks like this:
knowledge/
├── index.md
└── hotels/
├── index.md
├── aurora-bay/
│ ├── index.md
│ ├── neighborhood.md
│ ├── staff-service.md
│ ├── beach-access.md
│ └── contract-2025.pdf
└── marina-plaza/
├── index.md
└── neighborhood.mdEvery folder has an index.md that tells the agent what it will find below it:
# Aurora Bay
## Guest experiences
- [Neighborhood](neighborhood.md) - noise, nightlife, transport
- [Beach access](beach-access.md) - distance and route to the beach
- [Staff service](staff-service.md) - front desk and housekeeping
## Commercial
- [Contract 2025](contract-2025.pdf) - rates, source of recordEach document has its own frontmatter that states what it contains, where it comes from and who may read it:
---
type: PropertyNote
title: Aurora Bay - Noise
description: Street noise by room orientation
resource: knowledge/hotels/aurora-bay/neighborhood.md
tags: [noise, transport]
lifecycle: current
review_date: 2026-09-09
source: guest_reviews
visibility: agent_readable
---OKF only requires the field type and defines a small set of further fields, such as title, description, resource, tags and timestamp [8]. An advantage of OKF is that the frontmatter can be extended with custom fields, such as lifecycle, review_date, source and visibility in this example, which allows quality and governance information to be stored next to the content itself, where the pipeline and the agent can both use it. The consultants curate the documents, and the agent reads the same workspace read-only. Custom tools select the relevant documents, so there is no re-embedding cycle, and the frontmatter narrows each search before a single document is opened. Bringing the existing material into this structure is a one-time effort that an AI pipeline can support, and keeping it current afterwards means adding or updating one document at a time. The tiers of the pipeline appear in the frontmatter as the lifecycle states draft, reviewed, current and deprecated, and only current documents are visible to the agent, so an unverified review or an outdated staff note stays out of its reach in the same way an outdated rate does.
3. Governed: Least privilege, no shortcuts
Let's say Alex asks the agent to take the Aurora Bay rate straight from contract-2025.pdf, the source of record, and finds that the agent cannot open it: the contract is not marked as readable for the agent, and the rate comes from the checked gold table instead. How much access should an agent get, and what should it be allowed to execute? Direct access to the booking database would make the agent faster. Also, it would let the agent read and change more than a request needs. Governance applies on two sides.
On the data side, we define access in the metadata, through visibility: agent_readable in the frontmatter and through the contract for each structured feed. The curated tiers control what is visible, and permissions on the database and the document bucket restrict the agent's access at the source, so that a wrong instruction in a prompt cannot open data the agent is not supposed to see. On the agent side, an agent should have least-privilege, read-only access to the knowledge tree and work through custom tools only. We distinguish between two kinds of tools: trusted tools, which we developed and tested ourselves and which encode company policy, and code that the agent generates on its own, which is untrusted.
4. Traceable: Why this hotel
The offer for the family is a sea-facing room at the Aurora Bay for 238 € per night, based on a rate that is four hours old. When Alex presents it, the family asks why the agent picked this hotel and not one that is 20 € cheaper, and unlike the private chat answer at the beginning, this offer can be explained. How can a recommendation like this be reconstructed when an audit takes place, or when someone asks how the price was calculated and where it came from?
We found OpenTelemetry [9] to be well suited for such cases: it is an open standard for recording traces, metrics and logs, which more than 90 observability vendors support [9], and with it an agent records prompts, thinking traces and tool calls. In our projects at Posedio, we have seen both LLM-specific monitoring solutions such as Langfuse [10] and conventional tracing tools from software monitoring stacks such as Jaeger [11] used to analyse these traces. For a graph agent, such a record is essential, because it has to show which branch the agent took and why; without it, an audit is hardly possible. The trace records the metadata and references the payload instead of storing every piece of content:
agent.run session: sess_88a1
input: quiet room, Aurora Bay
output: 238 EUR/night
verdict: grounded
LLM_instructions 780ms
prompt: hotel_match@v7
tokens: 1840 in / 96 out
thinking_traces 310ms
steps: 3
plan: check rate, then noise
content: not recorded
tool_call: retrieve_knowledge 120ms
hit: neighborhood.md 0.91
hit: beach-access.md 0.44
tool_call: read_document 215ms
lifecycle: current
policy: allowWhen the family asks why the agent picked the Aurora Bay and not the hotel that is 20 € cheaper, the run can be replayed from a trace, node by node.
%%{init: {"theme": "base", "themeVariables": {"background": "#ffffff", "clusterBkg": "#f2f2f2", "clusterBorder": "#d0d0d0", "primaryColor": "#ffffff", "primaryBorderColor": "#9a9a9a", "primaryTextColor": "#222222", "secondaryColor": "#f2f2f2", "tertiaryColor": "#f2f2f2", "lineColor": "#666666", "edgeLabelBackground": "#ffffff"}}}%%
flowchart TB
q("Quiet room, Aurora Bay, July")
q -- "query: aurora bay noise" --> k("Retrieve knowledge")
q -- "query: AURORA-BAY-01" --> r("Rate lookup")
k -- "relevance 0,91" --> n("neighborhood.md")
k -. "relevance 0,44" .-> b("beach-access.md")
r -- "4 h old, within SLA" --> p("238 € per night")
r -. "not agent-readable" .-> c("contract-2025.pdf")
n -- "finding: quiet sea-facing rooms" --> a("Offer: Aurora Bay, 238 € per night")
p --> a
classDef skipped stroke-dasharray: 5 5,color:#777777
class b,c skippedThe diagram could not be rendered — here is its source.
The recommendation rests on the noise note, not on the price: the Aurora Bay was picked for its quiet sea-facing rooms, at a rate that was well within the 24-hour SLA.
5. Operational: From search to an offer Alex can approve
In the private chat, Alex would have had to copy every result into the agency's tools by hand. An agent that is connected to the booking system, the supplier rules and the quote and invoice process produces the package itself, and Alex reviews and approves it before anything is booked. Pricing the family's options falls into the second category of tools, code that the agent generates on its own, because the agent writes the SQL that combines flights and hotels. Even when that query is routed through a trusted tool, an LLM wrote it, so it runs in a sandbox. Options for the sandbox include Vertex AI Agent Engine code execution [12] or a container on a self-managed Kubernetes cluster.
%%{init: {"theme": "base", "themeVariables": {"background": "#ffffff", "clusterBkg": "#f2f2f2", "clusterBorder": "#d0d0d0", "primaryColor": "#ffffff", "primaryBorderColor": "#9a9a9a", "primaryTextColor": "#222222", "secondaryColor": "#f2f2f2", "tertiaryColor": "#f2f2f2", "lineColor": "#666666", "edgeLabelBackground": "#ffffff"}}}%%
flowchart LR
s1("Agent computes the pricing<br/>generated code such as SQL queries") --> s2("Sandbox runs it<br/>Vertex AI Agent Engine code execution or a container")
s2 --> s3("Audit the result<br/>plan, offer, pricing")
s3 --> s4("Wrong? Throw it away<br/>and run it again")
s4 -.-> s1The diagram could not be rendered — here is its source.
The sandbox isolates the execution, but not the access. Permissions still have to be enforced at the database level, an agent may only call tools that company policy authorizes, and every call is traced.
What you end up with
%%{init: {"theme": "base", "themeVariables": {"background": "#ffffff", "clusterBkg": "#f2f2f2", "clusterBorder": "#d0d0d0", "primaryColor": "#ffffff", "primaryBorderColor": "#9a9a9a", "primaryTextColor": "#222222", "secondaryColor": "#f2f2f2", "tertiaryColor": "#f2f2f2", "lineColor": "#666666", "edgeLabelBackground": "#ffffff"}}}%%
flowchart LR
subgraph agents["Agents"]
co("Coordinator")
subgraph search["Search: parallel"]
fl("Flights")
ho("Hotels")
end
subgraph match["Match: graph"]
ru{"Rules"} --> ra("Rank")
end
subgraph price["Price: loop"]
pr("Price") --> fi{"Fits?"}
fi -- "no" --> pr
end
subgraph pkg["Package: sequential"]
it("Itinerary") --> qu("Quote") --> inv("Invoice")
end
co --> fl
co --> ho
fl --> ru
ho --> ru
ra --> pr
fi -- "yes" --> it
end
subgraph data["Data"]
st("Structured") --> dc{"Data contract"} --> gt[("Gold tables")]
un("Unstructured") --> cu{"Curation"} --> okf[("OKF knowledge base")]
end
sb("Sandbox")
fl --> sb
ho --> sb
pr --> sb
sb -- "read-only" --> gt
ra -- "read-only" --> okf
agents -.-> tr[("Traces")]
inv --> con("Consultant") -- "approve" --> bk[("Booking")]The diagram could not be rendered — here is its source.
Generated code runs in a sandbox with read-only access to the gold tables, the agent reads the OKF knowledge base read-only, and every step is written to the traces. At the end of the chain, the consultant approves the offer before anything is booked.
The agent the company should have built before Alex started
This is how Alex works on the family's request with the agent, from the first search to her approval of the offer. The numbers are illustrative; let's say the family travels in the first week of July and stays seven nights. The request contains constraints from the family, from the agency and from the data contracts:
| Constraint | Set by | How the agent checks it |
|---|---|---|
| Four travellers, first week of July, seven nights | Family | Search parameters for flights and hotel rooms |
| No night flights | Family | Filter on departure and arrival times in the flight search |
| Quiet hotel | Family | Noise notes in neighborhood.md |
| Close to the beach | Family | Distance and route in beach-access.md |
| Friendly staff | Family | Staff notes in staff-service.md |
| Total price under 3.000 € | Family | Price loop in the sandbox |
| Supplier and cancellation rules | Agency | Decision tables in the graph |
| Rate not older than 24 hours | Data contract | Freshness SLA of the rate feed |
| Only current documents the agent may read | Agency policy | lifecycle and visibility in the frontmatter |
With these constraints, the agent works through the request in the following steps:
- The coordinator starts the flight search and the hotel search in parallel. The flight search drops a connection that departs at 23:40, because the family excluded night flights.
- The graph applies the supplier and cancellation rules to the hotels found and removes every offer whose conditions the agency does not accept.
- The agent ranks the remaining hotels with the notes from the knowledge base. Let's say the Marina Plaza costs 218 € per night, 20 € less than the Aurora Bay, but its neighborhood.md describes street noise at night, while the note for the Aurora Bay describes quiet sea-facing rooms. The Aurora Bay ranks first.
- The agent generates the SQL that combines flights and hotel, and the sandbox runs it read-only on the gold tables. Let's say the first combination uses daytime flights for 1.480 € and comes to 3.146 € with seven nights at 238 €, which is above the budget. The loop prices the next daytime connection for 1.120 €, which brings the total to 2.786 €, and the loop stops.
- Before the agent answers, it checks again that an indexed contract exists for AURORA-BAY-01, that the rate is four hours old and therefore within the 24-hour SLA, that the noise note has the lifecycle state current, and that policy allows the agent to read it. Depending on which check fails, the agent gives no answer, escalates the outdated rate, offers the note only as an unverified draft, or is refused access to the document. Here, the checks pass; the attempt to open contract-2025.pdf is denied, because the contract is not marked as readable for the agent.
- The package step creates itinerary, quote and invoice as plain function calls.
- Every step is written to the trace, and Alex, as the consultant, reviews and approves the offer before anything is booked.
6. Expandable: The next customer is a backpacker
Let's say the next customer is a backpacker who wants hostels and regional trains on a budget of 800 €. Alex starts no new chat and pastes no new documents; the agent can take the request on without a redesign, because each part of it has a defined place. Hostel rates arrive as a new feed with its own data contract and pass through the same bronze, silver and gold tiers. Reviews of hostels become new OKF documents with the same frontmatter, curated and checked in the same way. Train connections are a new trusted tool that encodes the agency's policy and is added to the tools the agent may call, so the sandbox, the permissions and the traces apply to it as they do to the others. The process keeps its building blocks: a parallel search, a graph with the agency's supplier rules, a price loop against the budget and a sequential package step.
The six pillars at a glance
%%{init: {"theme": "base", "themeVariables": {"background": "#ffffff", "clusterBkg": "#f2f2f2", "clusterBorder": "#d0d0d0", "primaryColor": "#ffffff", "primaryBorderColor": "#9a9a9a", "primaryTextColor": "#222222", "secondaryColor": "#f2f2f2", "tertiaryColor": "#f2f2f2", "lineColor": "#666666", "edgeLabelBackground": "#ffffff"}}}%%
flowchart TB
subgraph row1[" "]
direction LR
P1("Trusted<br/>The data it reads is correct and current")
P2("Contextual<br/>It knows what the data means")
P3("Governed<br/>Permissions and policy bound what it may do")
P1 ~~~ P2 ~~~ P3
end
subgraph row2[" "]
direction LR
P4("Traceable<br/>Every decision and tool call is recorded and can be traced back")
P5("Operational<br/>It can act in production environments")
P6("Expandable<br/>Capabilities can be extended without a redesign")
P4 ~~~ P5 ~~~ P6
end
row1 ~~~ row2The diagram could not be rendered — here is its source.
Each pillar addresses a part of what went wrong for Alex. In Alex's situation, an agent that bases its answers only on checked and current data (pillar 1, trusted) would have replaced the documents she pasted into the chat without knowing whether they were up to date. An agent that knows what the agency's data means (pillar 2, contextual) would have matched a wish like "quiet" against reviews and questionnaires, instead of depending on the excerpts Alex happened to choose. An agent whose permissions and policy decide what it may read and do (pillar 3, governed) would have kept the internal documents inside the agency, with no private account involved. An agent that records every decision and tool call (pillar 4, traceable) would have made every recommendation traceable to the documents behind it, which her chat answer was not. An agent connected to the booking system, the supplier rules and the quote and invoice process (pillar 5, operational) would have spared her copying results between a chat window and the agency's tools. Also, an agent that can be extended without a redesign (pillar 6, expandable) handles the next customer, a backpacker for example, instead of Alex starting a new chat with a new set of pasted documents.
Where to go from here
We at Posedio believe an agent does not have to start as a large platform; a single, well-defined business process, such as preparing an offer, is enough to find out which data the agent needs, which rules apply and who has to approve the result. Also, the travel agency in this post is one example among many: an insurance claim, a support ticket or a purchase order raise the same questions about data quality, access, traceability and approval, and we expect an agent for any of them to rest on the same six pillars.
This post is based on a talk by Martin Mayr and Adrian Dimaano on 24.09.2026 at the GCP Meetup Talk [13].
References
[1] Making Your Data Ready for Agentic AI, Pramod Sadalage and Prem Chandrasekaran, Accessed at 14-10-2026
[2] Microsoft and LinkedIn release the 2024 Work Trend Index on the state of AI at work, Microsoft, Accessed at 14-10-2026
[3] A Practical Guide for Designing, Developing, and Deploying Production-Grade Agentic AI Workflows, Eranga Bandara et al., Accessed at 14-10-2026
[4] 2026 State of Data Integrity and AI Readiness, Precisely and the Center for Applied AI and Business Analytics at Drexel University's LeBow College of Business, Accessed at 14-10-2026
[5] Open Data Contract Standard, Bitol (Linux Foundation AI & Data), Accessed at 14-10-2026
[6] What is the medallion lakehouse architecture?, Databricks, Accessed at 14-10-2026
[7] Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, Patrick Lewis et al., Accessed at 14-10-2026
[8] How the Open Knowledge Format can improve data sharing, Sam McVeety and Amir Hormati, Accessed at 14-10-2026
[9] OpenTelemetry Documentation, OpenTelemetry Authors (Cloud Native Computing Foundation), Accessed at 14-10-2026
[10] OpenTelemetry (OTEL) for LLM Observability, Langfuse, Accessed at 14-10-2026
[11] Jaeger Documentation: Introduction, The Jaeger Authors (Cloud Native Computing Foundation), Accessed at 14-10-2026
[12] Vertex AI Agent Engine Code Execution, Google Cloud, Accessed at 14-10-2026
[13] Google Cloud Meetup Vienna, Meetup, Accessed at 22-10-2026
