Let an assistant prepare reservations through controlled operations
Make useful application capabilities available without handing over the database.
What is difficult today?
An external assistant can discuss availability but cannot reliably act without an application contract. Giving it arbitrary database access is not a substitute for business rules. A narrow interface can expose the actions that make sense for an assistant while retaining the system’s existing authorization.
A Forge Project defines read-only search, eligibility checks and draft reservation creation. Final confirmation remains a separately permitted operation. The adapter calls the same application services as the ordinary interface and returns meaningful errors and repeat-safe results.
A sequence with accountable decisions.
The owner defines the target. The engineering work keeps the relevant business rules and returns evidence at each acceptance boundary.
Choose the operation surface
Start with reading availability and preparing a draft.
Specify contracts
Define input, output, identity and approval boundaries.
Build the adapter
Reuse application rules; add MCP only where appropriate.
Test forbidden calls
Reject cross-office access and unsupported commits.
Issue limited credentials
Grant the external assistant only its intended scope.
Data, rules and proof—not only screens.
Data involved
- Availability data with permitted visibility.
- Actor, office and operation-scoped identity.
Rules to preserve
- No unrestricted SQL or administrative API.
- A draft is not a confirmed booking.
- Repeated action keys return a coherent result.
Evidence to inspect
- Read operations cannot write.
- Out-of-scope writes are denied.
- Duplicate requests do not double-book.
- Documented error is returned for unavailable capacity.
Owner decisions
- Which assistant identities are trusted?
- Which confirmation steps need a person?
Expose business operations, not an unrestricted database
Start with operations a person could safely delegate: list permitted free slots, inspect a reservation visible to that principal and prepare a proposed change. Each operation has typed inputs, an authenticated actor, a result contract and explicit side effects. An agent-facing interface should reuse the application’s authorization and business functions rather than build a second weaker route around them.
A write operation can require a prior approval tied to the exact proposed change. Repeat-action safeguards keep a retry from creating a second reservation. Logs identify the operation and outcome without exposing secret credentials. Test a request for another customer’s record, an expired authorization and malformed arguments. MCP can be an adapter where it is suitable; it does not decide the access policy. The same business rule remains testable when a later Project modifies the reservation system.
Follow a related example from start to release.
A worked example showing decisions, implementation and verification.
The video could not be loaded. Try again later.
Prepare the next decision.
An API makes software reachable. A workflow makes AI useful
Separate technical connectivity from a controlled business process that reaches a defined result.
Read the guide →From enquiry to draft quote: a bounded AI workflow
Use AI to interpret the request without letting it invent prices, capacity or permission to send.
Read the guide →Classify documents without turning uncertainty into a wrong record
Design an extraction workflow with source evidence, clear categories and a real review queue.
Read the guide →Start with a product.
Keep building a business.
Bring an idea or the software you already own. Give the next improvement a clear path from intent to evidence.