Limited published evidence · Sales, legal operations and engineering
AI RFP contract agent experiments: Box example
In a January 2025 post on X, Box's CEO Aaron Levie described early internal experiments with agents that respond to RFPs and extract contract data, plus tests of external agents for bug fixes and SDK updates. His post calls this early experimentation and does not establish tools, test results or release outcomes.
Draft RFP responses, extract contract data, fix bugs and update SDKs
Box internal experiments
Early internal experimentation reported by Box's CEO in January 2025. Detailed deployments, controls and production outcomes are not established.
A published third-party example, not a Nuvepro customer case or evidence of a partnership.
The workflow at a glance
Early agent experiments across documents and code
Illustrative summary of the published account
Reported work components. Their arrangement does not imply a fixed execution order or simultaneous work.
- Internal document experiment
Draft RFP responses
Box’s CEO reports building an internal agent for RFP responses.
- Internal document experiment
Extract critical contract data
The stated purpose is downstream automation; schemas and resulting actions are not disclosed.
- External-agent experiment
Assist engineering bug fixes
The post reports testing agents; actual repositories, test results and merged changes are not shown.
- External-agent experiment
Update SDKs from feature requests
The post names this work category without establishing tool choice or release outcomes.
What the source reports
Aaron Levie describes Box building internal agents to respond to RFPs and extract critical contract data for downstream automation. He also reports testing external agents for engineering bug fixes and SDK updates driven by feature requests. The post explicitly characterizes this work as early experimentation. It supplies useful work categories, but does not establish the repositories, extraction schemas, specific agent products, test results, merged fixes or release outcomes.
Source accounts: @levie
Reported technology: Internal and external AI agents described by Aaron Levie; individual tools not specified. Scope and outcomes are source-reported.
What the enterprise environment would need
The following is a proposed project design for an enterprise doing similar work. Published details are marked; the remaining systems, data and scenarios would be agreed for your project.
Proposed practice environment
Review document and SDK drafts in separate workspaces
Illustrative project design to scope with your enterprise.
Checks designed, not executed. Domain owners must agree the reference results, permissions and acceptance tests before implementation.
- 1 · Set up the environment
Fictional documents and a test SDK
Provide RFP evidence, contracts/amendments, a reproducible issue and feature request.
- 2 · Document and engineering agents
Agents draft responses, extracts and changes
Separate document and engineering workstreams prepare response/extract drafts and candidate SDK diffs; no order or dependency between them is assumed.
- 3 · Independent checks
Independent source and regression checks
Independent reviewers verify source passages and contract amendments; engineers reproduce the bug and run regression and existing-client compatibility checks.
- 4 · People decide acceptance
Sales, legal and engineering owners review
Sales, legal/operations and engineering owners accept their respective practice outputs. Submission, contract action, merge and release remain separate authorities.
A reviewable evidence package
An evidence-backed RFP draft, contract extract and bounded SDK change package.
If a check fails → withhold acceptance.
A plausible SDK fix breaks an existing client. Reject it despite passing the new-feature check.
Failure or owner rejection returns to review
- Hold
- → 2 · Repair the affected draft or code change
- → 3 · Rerun independent checks
- → 4 · Owner review
Operating boundary. No external submission, contract action, merge or release without its designated owner.
- Systems and tools
- Source-described: RFP, contract and engineering agent experiments, with individual tools unspecified. Proposed: use a controlled document workspace and separate test repository for each workstream.
- Data and state
- Proposed: provide fictional RFP requirements, approved product evidence, linked contract/amendment records and a small SDK repository with a reproducible issue and feature request.
- People and handoffs
- Proposed: sales reviews commitments, legal/operations reviews extracted contract meaning, and engineering reviews diffs, tests and compatibility. The post does not establish these implemented controls.
- Rules and authority
- Proposed: separate drafting from external submission, contract interpretation from consequential action, and candidate code changes from merge/release authority.
- Normal and exception cases
- Proposed: test unsupported RFP commitments, conflicting amendments, an unreproduced bug and a feature that breaks an existing SDK client. These cases are our proposed extensions.
- Reset and replay
- Proposed: restore document versions and clean repository commits, then replay each task with the same approved evidence and held-out regression suite. No reset system is published in the post.
A proposed simulation
An illustrative practice design derived from this work, not an executed assessment.
Proposed: prepare one evidence-backed RFP draft and contract extract, then demonstrate a bounded SDK bug fix and feature change in a test repository.
Review gate: Proposed: sales/legal owners verify evidence and retained authority, while engineers reproduce the issue and accept regression and compatibility results for the candidate changes.
Challenge the result: Proposed: an agent produces a plausible SDK fix that breaks an existing client. Passing the new feature check alone must not qualify the change for release.
What needs checking
- Proposed: verify RFP claims and extracted contract fields against authoritative source passages; preserve uncertainty and missing evidence.
- Proposed: reproduce the bug before the fix, run meaningful regression and compatibility tests, and inspect the actual diff and resulting repository state.
- Proposed: test that no response is submitted, contract action executed or code released without its designated owner's approval.
Review environment fidelity, human capability and agent performance separately. The enterprise’s accountable owners decide acceptance of the shared workflow and any operating use.
Questions about this example
- What is Box experimenting with AI agents for?
- In his post on X, Aaron Levie describes Box building internal agents to respond to RFPs and to extract critical contract data for downstream automation. He also reports testing external agents for engineering bug fixes and for SDK updates driven by feature requests.
- Who reviews the agents' work at Box?
- Aaron Levie's post does not establish who reviews the agents' work or any implemented controls. As proposed checks, not reported practice, sales would review RFP commitments, legal and operations would review extracted contract meaning, and engineering would review diffs, tests and compatibility.
- How strong is the evidence for this example?
- Weak. It is an operator account from Aaron Levie of early experimentation, posted on X in January 2025, not proof of present-day deployment or verified outcomes. Specific tools, input schemas, evaluation results and downstream effects are not disclosed, and no external customer is named.
- What would an enterprise need to build something similar?
- This is Nuvepro's proposed design for discussion, not Box's setup. It would use a controlled document workspace and a separate test repository per workstream, fictional RFP and contract records, restored versions for replay, and separate authority for submission, contract action and merge or release.
Shape this around your enterprise
Bring a similar workflow and the people responsible for it. Together, define the records and systems to use, the result your team will build or configure, and how its owners will check it. Nuvepro scopes the simulation, environment and preparation. Agree any existing-agent evaluation, implementation assistance and production responsibilities separately.
Sources and limitations
Curation review: . This is the date this source example was reviewed, separate from source publication dates.
- The source is an early operator account, not proof of present-day deployment, verified outcomes or a named external customer. Only the directly read opening supplies these four work examples.
- Specific tools, input schemas, evaluation results and actual downstream effects are undisclosed; detailed environment and control choices above are proposed.
- The proposed environment, practice project and checks are designs for discussion, not executed Nuvepro work or evidence of production readiness.
- Early internal agents for RFPs, contract extraction and engineeringSource publication: 2025-01-17