The AI Fabric: A Research Thesis on Loops, Graphs and Everyday Coordination

Abstract

This paper proposes an AI fabric: a persistent coordination layer connecting people, responsibilities, records and services through relationship graphs, bounded feedback loops and enforceable authority. Its purpose is to reduce the human effort required to carry context between applications and keep unfinished work moving. The proposed fabric connects layers of identity, preferences, needs, time, location, access and evidence while preserving boundaries between individuals and organizations. A selective review of research on ubiquitous computing, language-model agents, memory, authorization and provenance establishes relevant foundations. The paper then develops a conceptual model, examines operational scenarios and proposes an evaluation method. Its central hypothesis is that shared, permission-aware context can reduce coordination effort compared with isolated assistants and disconnected workflows, provided the cost of correction, oversight and recovery does not cancel those gains. This is a conceptual contribution, not a report of experimental results. The proposed evaluation has not been conducted, and the wider vision does not describe a fully delivered Dryvn capability.

Keywords: AI fabric; agentic AI; agentic workflows; knowledge graphs; feedback loops; contextual computing; AI permissions; human oversight; business operating systems.

1. The thesis: AI as connective tissue

I think AI will become a tightly woven fabric running through everyday life. Layer upon layer of connective tissue between the people we know, the work we do, the things we need and the systems we rely on.

Our likes and dislikes. Our responsibilities. Where we need to be. Who we trust with particular information. What someone can approve. What changed this morning, and what that change means for the rest of the day.

The ambition is a system that can carry those relationships forward into useful work.

I came to this through operating work and building Dryvn. A customer request rarely stays inside one screen. It touches a person, a property, a schedule, a trade, a promise and a follow-up. The records can all exist while the owner still has to remember how they fit together. Three screens and twenty tabs can leave the most consequential part of the system running in someone's head.

My thesis is that AI becomes more useful when it can coordinate across those relationships under explicit authority, maintain progress through interruptions and establish what actually happened.

That is a stronger claim than saying AI can answer questions or operate tools. It is also a claim that needs testing. A connected system that creates more supervision than it removes has failed its purpose, even if its demonstrations look impressive.

What is an AI fabric?

This definition is specific to the paper. It does not establish ownership of the phrase “AI fabric,” a new scientific category or priority over related work. The contribution is a synthesis: bringing these responsibilities into one operational model and setting out how its usefulness could be measured.

2. Research question and method

The main research question is:

Can a persistent, permission-aware coordination layer reduce the human effort needed to complete work across multiple systems without increasing consequential errors or inappropriate actions?

Three supporting questions follow. What context must remain available between tasks? How can coordination span people and organizations without unrestricted access? And how can a person retain meaningful control when work continues outside the active conversation?

This paper uses a selective narrative review of primary research, standards material and first-party engineering documentation. Sources were chosen for their direct relevance to five responsibilities: interaction, agent execution, memory, authorization and evidence. Academic papers provide research grounding; technical documentation illustrates implementation concepts; security guidance identifies failure conditions. These sources have different evidentiary weight and are identified accordingly.

This is not a systematic literature review. No exhaustive database search, market census, participant study or production benchmark was performed. Research abstracts and relevant documentation were used to establish the bounded claims cited here; the paper does not reproduce or independently validate their experiments. The scenarios and evaluation design are proposed by the author.

The approach supports a reasoned position paper. It cannot establish that this combination is unprecedented, universally preferable or commercially proven.

3. Related research: the foundations already exist

3.1 Computing that recedes into everyday activity

Mark Weiser's 1991 work on ubiquitous computing described computing becoming integrated into ordinary environments and activity. That establishes a historical foundation for the idea that people should not need to focus continually on the computer itself. It does not establish the agentic execution model proposed here.1

The implication for this paper is limited but useful: an interface can become less demanding while the underlying system becomes more capable. The goal is reduced attention spent operating software, with control still available when it matters.

3.2 Reasoning connected to action and feedback

Yao and colleagues' ReAct research explored interleaving language-model reasoning with actions that obtain information or interact with an environment. It reported results on particular question-answering and interactive decision-making tasks.2

This supports the use of action and observation within a task. It does not demonstrate reliable operation across an entire business, persistent authority between organizations or safe long-term autonomy. Those remain separate requirements in the proposed fabric.

3.3 Workflows and agents have different roles

Anthropic's 2024 engineering account distinguishes workflows with predefined execution paths from agents that dynamically direct their own processes and tool use. It argues for using complexity where the task warrants it.3

That distinction matters here. A known reminder process may need ordinary software rules. An ambiguous customer request may benefit from a model interpreting what the person means. Both can participate in the same coordinated environment. Making every step an autonomous decision would introduce uncertainty without necessarily improving the result.

3.4 Memory can influence subsequent behaviour

Park and colleagues' Generative Agents research combines stored experiences, retrieval, reflection and planning in a simulated environment. Its evaluation concerns believable behaviour among simulated agents.4

This is relevant to continuity: previous observations can affect later action. It is not evidence that an assistant has correctly understood a real person's needs, obtained valid consent or produced a reliable record. The proposed fabric therefore treats memory as information requiring inspection and correction.

3.5 Authorization and evidence have established foundations

Google's Zanzibar paper describes a deployed authorization system with a common model for access decisions across services and consistency as permissions and content change.5 NIST's zero trust publication rejects implicit trust based solely on network or physical location or ownership.6 The W3C PROV family provides models for describing the entities, activities and people involved in producing information.7

These foundations address different questions: whether access is permitted, which trust assumptions are appropriate, and where a record came from. The fabric proposal needs all three. None of these sources alone establishes an AI operating environment.

3.6 What remains unproven

The literature reviewed here supports component ideas. It does not demonstrate that combining them will reduce the total burden of coordination in the situations described below.

That is the gap this paper addresses conceptually and proposes to evaluate. It is a gap in the evidence presented here, not a claim that no other researcher or company is working on it.

4. The conceptual model: one fabric, multiple connected views

I picture one fabric because the experience should retain continuity. A request should not lose its owner, history or authority when it crosses from a conversation into a calendar or from a field worker to an office process.

“One” describes that continuity. It does not require one global database or one graph engine. A logical graph can represent a connected environment while its records remain distributed across separately controlled systems. Different applications may use different internal representations.

Three views are useful in this proposed model:

These are conceptual views, not a requirement for three separate databases. Authority applies to each view. A relationship being discoverable does not mean every participant may inspect it or take action through it.

LangGraph's documentation illustrates graph-based execution using shared state, nodes and edges.8 A graph is not inherently intelligent, and a graph without a cycle is not inherently static: it can branch, process changing inputs and run repeatedly. A feedback loop is a recurring control pattern that may be represented by cycles or managed by surrounding software. Pairing the terms “graph” and “loop” does not itself establish autonomy.

The larger proposal is that relationships, execution and evidence remain connected through time. A new event can change what the system knows, which work is relevant and whether a proposed action is still permitted.

The dimensions that give a relationship meaning

A connection between two records is incomplete without context. In this model, a relationship may need an owner, purpose, source, time of observation, period of validity and permitted uses.

“Alex is assigned to this job” could mean assigned today, provisionally assigned next week or formerly responsible for the job. Treating all three as equivalent could send information to the wrong person or produce a false commitment.

The proposed fabric therefore needs more than connectivity. It needs qualified relationships whose meaning can change without silently rewriting history.

5. The layers of the fabric

The following layers describe responsibilities. They are a public conceptual model, not a disclosure of Dryvn's internal implementation.

The layers are interdependent. A customer may prefer a morning appointment, but the assigned worker may be unavailable. A replacement may be qualified but lack site access. The person requesting the change may be allowed to propose it without being allowed to confirm it.

A useful system must carry those distinctions into the decision. Collecting every available detail is not the objective. The objective is enough relevant, authorized context to make or prepare the appropriate next move.

6. Personal context: likes, needs, people and place

Personalization becomes consequential when it changes action.

“I like morning appointments” describes a preference. “I cannot attend after noon” describes a constraint. “You may book a morning appointment with this supplier” grants bounded authority. A system that combines these into a general belief about what I want has discarded information it needs to behave properly.

For this proposal, personal context would carry distinctions between stated and inferred information, temporary and continuing instructions, and personal and organizational scope.

A repeated behaviour may justify a suggestion. It should not automatically become permission. If I repeatedly accept early meetings, the system could ask whether that is a useful preference to remember. It should not infer that I want every future morning filled.

People belong to several contexts

The same individual can be an owner, employee, customer, parent and member of another organization. Authority follows the relevant role and situation. It does not flow automatically between them.

A business scheduling process could learn that I am unavailable without learning why. A subcontractor could receive the approved scope and site address without receiving the customer's unrelated records. A household assistant could participate in arranging an appointment without acquiring control over a company's schedule.

This paper proposes selective disclosure as a condition of expansion. Shared coordination must work with limited information, including explicit statements such as “unavailable” or “approval required.” If useful coordination depends on complete access to everyone's life, the model is too demanding.

Location is time-bound evidence

Location can help estimate arrival times and identify which appointment is relevant. It can also be stale, inaccurate or unnecessarily intrusive.

The proposed model would distinguish a job's address, a person's stated destination, an estimated arrival and a device observation. Each answers a different question. Presence near a property would not establish permission to enter or readiness to perform work.

Location would have a defined purpose, an appropriate level of precision and an expiry appropriate to that purpose. A one-time arrival estimate need not become a permanent movement history. This is a design requirement of the proposal, not a claim of compliance with every applicable law.

Memory must be revisable

A person needs to inspect, correct and withdraw remembered context. A correction also needs to affect pending work that depends on the old information.

If a customer changes their contact preference, updating a profile while leaving several queued messages untouched would be an incomplete correction. If an inference is withdrawn, later tasks should not quietly recreate it from an old derived record.

The paper leaves the exact deletion and propagation mechanism open. The requirement is observable behaviour: withdrawn context must stop influencing actions where continued use is no longer authorized.

7. Embedded security: authority travels with the work

Security in this model is a condition of reading, deciding, acting and reporting. It cannot depend on a model remembering to behave appropriately.

OWASP's excessive-agency guidance identifies risks from unnecessary functions, permissions and autonomy, and recommends enforcing authorization in downstream systems.9 Its prompt-injection guidance describes the risk of outside content redirecting an AI application and the limits of available mitigations.10

These sources support a bounded conclusion: an AI application's language understanding is insufficient as its security boundary. The following requirements are this paper's proposed application of that conclusion.

An action would retain an accountable requester, a defined purpose, permitted resources, applicable constraints and any required approval. Authority would be checked when execution occurs, because it may have changed since the request began.

A message arriving from a customer could supply facts or request a change. It would not gain the right to modify the owner's approval rules. A document's apparent urgency would not upgrade its authority.

An approval would apply to a specific proposal. If the recipient, price, scope or timing changes materially, the prior approval may no longer cover the action. The record must preserve what the person actually agreed to.

Revocation needs equally precise behaviour. Work waiting for a future event must stop when its authorization is withdrawn. Work already completed may require a corrective action. An action in flight may need reconciliation before its outcome is known. Describing all three as “cancelled” hides differences the user needs to understand.

Related practical guidance: what AI should be allowed to do without asking.

8. Loops that wait, adapt and finish

An everyday workflow often spans hours or days. It needs continuity beyond the open conversation.

An estimate follow-up may begin with an approved message, wait for a reply, encounter a question about scope, pause for a decision and end with acceptance, rejection or expiry. Its outcome is not established by the first message being sent.

The proposed loop has a defined goal, observable state, permitted next actions, waiting conditions and terminal outcomes. Completed, declined, cancelled, expired, blocked and handed to a person should remain distinguishable.

A waiting process would preserve progress and resume on an appropriate event or deadline. This paper does not propose keeping a model continuously generating while nothing changes. It also does not assume repetition will eventually solve every problem. Resource limits, unsuccessful attempts and unresolved ambiguity can justify stopping.

Several loops can collide

The strongest difficulty appears when work overlaps. A sales workflow can promise capacity that a scheduling workflow has already consumed. Two assistants can offer the same slot. A purchasing workflow can spend funds that another process assumed remained available.

The proposed fabric needs to identify shared commitments before treating local progress as global success. Tentative options must remain distinguishable from confirmed commitments. If two operations compete for a scarce resource, the outcome must reflect an agreed priority or a human decision.

There is no universal formula for whose preference wins. The company's rules cannot automatically override a customer's consent, and a household obligation cannot automatically authorize a business change. Some conflicts are legitimate decisions between people. The system's job is to present them accurately and avoid manufacturing agreement.

Uncertain outcomes require reconciliation

If an appointment request times out, it may still have reached the calendar service. An immediate retry could create a duplicate.

In the proposed model, the state would remain “outcome unknown” until the authoritative record resolves it or a person takes responsibility. Recovery could involve checking the existing record, continuing from a confirmed step or arranging a corrective action. Repeating the entire workflow is not a general recovery strategy.

9. An operational scenario: a supplier delay across work and life

Consider an illustrative contractor with an installation scheduled for the afternoon. A supplier reports a delay. The owner also has a private commitment later that day, and the customer needs advance notice of any appointment change.

A coordinated response would begin by establishing which delivery and job the notice concerns. A similar address or customer name would not be enough if the association remained uncertain.

The fabric would then identify the affected commitments. Has the delivery time been confirmed? Is the assigned trade available at an alternative time? Does the change require customer agreement? Would it create a cost? Which parts can be prepared or executed under existing authority?

The owner's personal calendar could disclose the unavailable period without disclosing the private event. The customer's preference would affect how the proposed change is communicated. A supplier estimate would remain tentative until confirmed.

If the customer declines, the work returns to the available options. If the trade's availability changes during approval, the proposal is reassessed. If the supplier system is unavailable, unrelated work can continue while this dependency remains unresolved.

The owner sees what changed, what was handled and what requires judgment. That is the intended experience. This scenario is a proposed test case, not evidence of a deployed capability.

10. Everyday use beyond the business

The same conceptual structure could apply to ordinary personal coordination, though each domain introduces its own constraints.

Imagine arranging a family dinner. One person has a dietary requirement, another prefers an early evening, someone is travelling and two people have private calendar commitments. A useful system could exchange permitted availability and requirements, propose feasible options and record acceptance.

Knowing a restaurant preference would not authorize spending. Knowing that someone is travelling would not grant access to their precise location. One participant's assistant would have no automatic right to speak for everyone else.

This example matters because it tests whether the proposed fabric can coordinate through partial knowledge. Participants need not share the same software or expose their complete preferences. They need a way to exchange limited, meaningful proposals and confirm what has been agreed.

Extending that pattern to connected devices would increase the consequences of mistakes. Physical actions require controls appropriate to the device and environment. This paper does not infer that permission to manage a calendar is sufficient to operate a door lock or any other physical system.

11. Alternatives, counterarguments and limits

A well-integrated application suite may be sufficient

A business operating mostly inside one coherent suite may already have the necessary records, permissions and workflows. An additional coordination layer could add cost and maintenance.

The fabric's benefit would need to be demonstrated where work crosses meaningful boundaries. Integration alone is not a reason to introduce another system. A practical starting point is connecting the business software you already run.

Deterministic automation may be the better tool

Where inputs, rules and exceptions are known, ordinary automation can be easier to inspect and less variable. The proposal allows deterministic steps and should be compared against a competent automation baseline, not only a deliberately inefficient manual process.

AI earns its place where interpreting variable information or proposing responses to ambiguity improves the measured outcome.

Shared context can spread mistakes

A wrongly linked customer or outdated instruction could affect several workflows. More connectivity increases the number of places an error may matter.

The proposed response is selective propagation, visible uncertainty and bounded failure domains. These are requirements to test. Describing the system as layered does not prove it contains errors.

People may want less personalization

Useful assistance does not imply consent to extensive profiling. Users may prefer a less personalized system that asks occasional questions and retains less information.

The fabric should remain useful with restricted context. Otherwise the supposed convenience could become pressure to disclose more than someone wants to share.

Invisible work can undermine control

Removing interface steps can also remove opportunities to notice mistakes. Voice and conversational interfaces are useful entry points, but some decisions need a visible comparison, schedule or record.

The proposed direction is a flexible interface over continuing work. It does not require eliminating dashboards or replacing every interaction with conversation. Inspection and intervention are part of the product's function.

The economics may not work

Configuration, integration maintenance, model use, review and recovery all cost time or money. A system can complete more actions while becoming more expensive to operate.

This is why agent counts, message counts and apparent activity are weak measures of value. The relevant question is what it takes to produce an acceptable outcome, including the work required when the normal path fails.

12. How the thesis could be tested

The central hypothesis is falsifiable: sharing relevant context and coordinating dependencies should reduce total human coordination effort while preserving task quality and authority boundaries.

A proposed study would compare three conditions using the same task definitions and underlying records:

1. Existing applications with human coordination and available ordinary automation.
2. Task-specific AI assistance without a shared coordination layer between workflows.
3. The proposed fabric with shared, scoped context and coordinated task state.

Where practical, the two AI conditions would use the same model version and tool access. Differences in model capability must not be mistaken for benefits from the coordination model. Task sets would include both familiar workflows and exceptions, with order varied to reduce learning effects.

Measure the entire cost of an acceptable outcome

Before testing, define what counts as success, the task population, severity categories and acceptable tradeoffs. Report abandoned and unresolved tasks as well as completed ones. A lower average completion time that hides serious mistakes would not support the thesis.

Sample size would follow pilot variability and the chosen effect to detect; this paper supplies no invented participant count or statistical result. Confidence intervals and differences between task types would matter more than a single headline percentage. Rare severe failures would require targeted testing beyond an ordinary productivity trial.

Test what breaks first

The test set should include incorrect identity matches, stale location, changed preferences, withdrawn access, conflicting reservations, malicious instructions inside documents, missing replies and timeouts after possible execution.

Each case needs an expected acceptable response. That may be safe completion, a bounded pause or an explicit handoff. Universal completion would be the wrong target when the available evidence or authority is insufficient.

A component-removal study could then test the contribution of shared context, coordinated commitments and evidence-based reconciliation separately. Removing one component at a time would help distinguish the value of the proposed model from the value of adding AI at all.

Evidence that would weaken the thesis

The thesis would be weakened if the fabric required more total human effort, increased consequential mistakes, failed to respect withdrawn authority or offered no meaningful improvement over a well-configured suite. It would also be weakened if gains disappeared once maintenance and recovery were included.

No such study is reported here. The evaluation is a proposed research programme, and the wider benefits remain hypotheses.

13. What this means for Dryvn

I am building Dryvn as an AI-powered business operating system for trades contractors. The operating problem behind this paper is directly relevant: requests, responsibilities and follow-through cross people and systems every day.

The AI fabric is my broader view of where that direction could lead. It connects business coordination with the wider context of everyday life while preserving the boundaries around each participant.

This paper does not claim that Dryvn has implemented or validated every layer, scenario or evaluation described. It also does not publish proprietary prompts, internal architecture or implementation methods. Public discussion can establish the problem, the principles and the evidence needed without disclosing the build underneath them.

The progression I see begins with a bounded responsibility: a clear owner, relevant context, enforceable authority and a verifiable outcome. Its connections can expand as evidence shows that doing so improves the overall operation.

14. Conclusion: continuity is the outcome

The fabric I imagine is tightly woven because the parts inform one another. A change in a delivery can affect a job. A job can affect a customer's plans. A personal commitment can constrain the available options without exposing private details. An approval can permit one action while leaving another outside scope.

Graphs can describe those relationships and dependencies. Loops can keep work moving through observation and feedback. The harder requirement is preserving meaning, authority and evidence as the situation changes.

Existing research supports several foundations. The complete coordination model and its value still require evaluation. The test is whether people spend less effort holding the operation together while retaining control over consequential decisions.

I want less of my day spent carrying information between systems and remembering which loose end belongs to whom. I want that time back for the business, the people relying on me and the life happening around the work. That is the outcome this concept needs to earn.

Questions about AI fabrics, loops and graphs

How do graphs and loops work together in AI?

Graphs represent relationships or possible execution paths. Feedback loops revisit a process after observing what happened. In an AI workflow, their combination can support branching, retries and adaptation. Reliable execution also requires saved state, permitted tools, stopping conditions and evidence of results.

Is an AI fabric the same as a knowledge graph?

A knowledge graph represents entities and relationships. The proposed AI fabric includes connected context but also governs action, workflow continuity, authority, correction and evidence. A graph representation alone does not provide those responsibilities.

Does one AI fabric require one model or database?

No. In this paper, “one fabric” means continuity across permitted work. Records and services can remain separately controlled, provided their interactions preserve relevant meaning, authority and outcomes.

Will agentic AI replace application interfaces?

That is not established. This paper proposes reducing routine navigation while retaining interfaces for inspection, complex decisions and correction. Conversation, voice and visual controls can provide different ways into the same continuing work.

Can personal context make autonomous AI safe?

Personal context can improve relevance, but it does not establish permission or safety. The proposed model requires separately enforced authority, limited disclosure, correction, recovery and testing. Knowing a preference is not permission to act on it.

Is this a proven Dryvn capability?

The wider AI fabric is a research-backed founder thesis. This paper presents no experiment or production evidence demonstrating the complete model. Current product capability must be assessed separately.

Explore Dryvn AI to understand the business problem behind this direction.

References

Sources reviewed September 13, 2026. Citations support the specific component claims where they appear; they do not validate the complete proposed fabric.

1. Weiser, M. (1991). The Computer for the 21st Century. Scientific American, 265(3), 94–104. Author text hosted by Stanford. Historical conceptual foundation.
2. Yao, S., Zhao, J., Yu, D., Du, N., Shafran, I., Narasimhan, K., & Cao, Y. (2023). ReAct: Synergizing Reasoning and Acting in Language Models. ICLR 2023; first preprint 2022. Paper and abstract. Research on interleaved reasoning and action in defined tasks.
3. Anthropic. (2024, December 19). Building effective agents. Engineering article. First-party engineering guidance; cited for conceptual distinctions, not current tooling recommendations.
4. Park, J. S., O'Brien, J. C., Cai, C. J., Morris, M. R., Liang, P., & Bernstein, M. S. (2023). Generative Agents: Interactive Simulacra of Human Behavior. UIST 2023. Paper and abstract. Research on memory and behaviour in simulation.
5. Pang, R., et al. (2019). Zanzibar: Google's Consistent, Global Authorization System. USENIX ATC 2019. Google Research publication. Deployed authorization-system research.
6. Rose, S., Borchert, O., Mitchell, S., & Connelly, S. (2020). Zero Trust Architecture. NIST SP 800-207. Publication. DOI. Security architecture guidance.
7. W3C. (2013, April 30). PROV-Overview. W3C Working Group Note. Overview of the provenance family; the overview itself is non-normative.
8. LangChain. Graph API overview. Technical documentation. Illustrates state, nodes and edges; not empirical evidence for the fabric.
9. OWASP Gen AI Security Project. LLM06:2025 Excessive Agency. Security guidance. Functions, permissions, autonomy and downstream authorization.
10. OWASP Gen AI Security Project. LLM01:2025 Prompt Injection. Security guidance. External-content attacks and mitigation limits.

Editorial claim note

This is a founder position paper, not a peer-reviewed publication. It reports no experiment, benchmark or production result. The cited sources support the specific component claims beside them and do not validate the complete proposed fabric. Nothing here describes a delivered or validated Dryvn capability.