Open Functions Core Laravel Package

Product Decisions This Supports

• Build vs. buy vs. adopt: This package sits on the "adopt/fork" side of the decision for LLM function-calling plumbing — schema generation, tool registration, tool-call parsing/delegation, and response formatting. It gives us a concrete alternative to writing that boilerplate ourselves or buying a heavyweight AI platform.
• AI/assistant roadmap scoping: Supports prioritization of assistant and agentic features — copilots, internal ops assistants, data-query agents, workflow automation — by making "each tool = one capability" a clean unit of product scope, entitlement, and feature-flagging.
• Vendor strategy: A provider-agnostic tool layer reduces lock-in to a single LLM vendor's SDK shape, supporting the decision to abstract model access rather than couple to one provider's message format.
• Architecture choice: Framework-agnostic core (portable, testable, reusable outside a single app) vs. framework-coupled code. Informs whether the AI layer lives in Laravel app code or as an internal package.
• Quality and safety investment: Centralized message handling creates natural seams for logging, evaluation harnesses, guardrails, and cost/token instrumentation — decisions about observability and safety spend get cheaper when the layer is standardized.
• Make vs. extend: Because it's a small, unopinionated core, it can be treated as a base to fork/extend rather than a platform commitment — a lower-commitment path that still reduces time-to-first-feature.
• Release decision: Whether to ship AI tool-use features on a thin dependency vs. wait for a more mature (or self-built) substrate — a speed-vs-supply-chain-risk tradeoff.

When to Consider This Package

Consider it when:

• You are building LLM features in a PHP/Laravel codebase that need multiple callable functions/tools, not just single-shot completions or chat.
• You want to cut boilerplate around JSON schema definitions, tool registration, tool-call dispatch, and result formatting.
• You expect to swap or support multiple LLM providers and want the tool layer decoupled from any one SDK.
• You need a registry/abstraction pattern quickly for a prototype or internal assistant and have engineering capacity to evaluate and own a thin dependency.
• You are comfortable wrapping it behind an internal interface and pinning/forking if needed.

Look elsewhere / avoid when:

• Production-critical work requires procurement, SLA, security review, or a long support horizon — zero stars and zero dependents signal no proven adoption or community support.
• The team is not PHP/Laravel-first (see JS/TS or Python equivalents).
• Needs are simple: one or two functions can be handled with direct SDK calls; the abstraction cost isn't repaid.
• You expect a platform (orchestration, tracing, evals, vector store, admin UI) — this is a core library, not a platform.
• You require documented Laravel integration (service provider, config publishing, facades) — verify it exists and is maintained before committing.
• Regulatory or compliance constraints require mature, actively maintained dependencies with an auditable history.

Mitigations if adopting: timeboxed spike on one feature; verify license and maintenance cadence; wrap behind an internal adapter; pin the version; keep a fork path open given the small surface area.

How to Pitch It (Stakeholders)

For executives:

• What it is: a small PHP library that standardizes how we define and expose "tools" our AI assistants can call — the plumbing behind assistant/agent features.
• Why it matters: it reduces integration effort and keeps us LLM-vendor-neutral, accelerating time-to-market for AI features without locking us to one provider or a large platform contract.
• Cost and risk: free OSS, but early-stage (zero stars, zero dependents). The right posture is a short, timeboxed evaluation wrapped behind our own interface so the dependency is replaceable.
• Ask: approve a small spike (a few engineering days) to validate on a single feature; no long-term commitment until it proves out.

For engineering:

• Provides a function registry, schema/message handling, and response formatting layer — removes repetitive glue code and standardizes the tool surface.
• Framework-agnostic, so it integrates into Laravel via a thin service provider/container binding we control, and is easy to unit test.
• Recommend an internal adapter interface, pinned version, and a fork-if-needed stance — the code surface is small enough to own.
• Key risk is maintenance maturity and undocumented Laravel ergonomics; both are addressed by the spike, the wrapper, and a vendoring fallback.